9 ms·

The reasons given are reasons to stick with C89 forever. Change has risk, and there are advantages and disadvantages. If there were no advantages gained from C9

The reasons given are reasons to stick with C89 forever. Change has risk, and there are advantages and disadvantages. If there were no advantages gained from C99, it wouldn't exist (people don't release language updates for no reason). A much more interesting question is if you were writing curl today, what would you do. If the answer is still 'C89' then we as a profession have to wonder why - did we get it exactly right, and there are no lessons from the last 30 years, or is the fact there are no better alternatives deeply depressing.

sfpotter 4y ago
The requirements for writing curl are different from the requirements for writing other software. Just because C89 is a good choice for curl doesn't mean that C99 isn't a better choice for other things. The failure isn't in having revised a language, it's in thinking that all projects using the older version must upgrade. The idea that progress is linear is an illusion.
throwaway0x7E6 4y ago
some things actually just work
BiteCode_dev 4y ago
The question is more complicated than that: curl is so popular it is used on systems where c99 is not available. The question is how many of those exist, and are at which point it's not worth supporting them anymore.
- UncleOxidant 4y ago
  > curl is so popular it is used on systems where c99 is not available. What systems don't support a version gcc that compiles c99 at this point?
  - BiteCode_dev 4y ago
    Old systems in ports and airports, military systems, anything that has a 50 years shelve life...
    - UncleOxidant 4y ago
      How many old systems like that are connected to the internet and could actually use curl?
      - nibbleshifter 4y ago
        Quite many!
      - BiteCode_dev 4y ago
        More than you would think, but curl is used to talk to the local network too, or inside VPN as well. Some hacks are quite crazy. E.G: there is this very old navy broacasting protocol, NMEA (https://en.wikipedia.org/wiki/NMEA_0183 https://en.wikipedia.org/wiki/NMEA_0183), that was designed so it could be transmitted through old fashion radio waves. You'll find it in some sonars, water sensors or AIS beacons. For this reason, despite that it looks more like a layer 4 protocol, it embeds its own packet format and checksum, all in ASCII, that clients are expected to parse. Now of course, a lot of devices are still emitting their data in NMEA, and it's not uncommon to be able to just telnet or netcat (if UDP) into one to see the data flowing. But after a while, people started to aggregate those data from their numerous sources into one single router, and expose this router for convenience through... HTTP over TCP/IP. And now you have those all those old computer towers (some still rocking a CRT screens or windows xp) doing long polling to get broadcasting data over a protocol that was made for request/reponse, to read the payload that is another protocol that was meant for radio equipment and hence requires manual consistency checks, that is transported by yet another protocol that is doing its best to preserve packets. And they say the spirit of hacking is dead :) (sometimes I feel IoT or domotic stacks look the same honestly) Of course, somewhere in there, there is a curl call. The question is therefore does curl author want to support a potential upgrade path for such twisted use case or not. I would say "nahhhh", but maybe curl had precisely the success it did because the author was ready to support it in crazy settings.
  - deleted 4y ago
    [deleted]
- bhawks 4y ago
  Just a terminology rant: it is used in -builds- where c99 is not available. Particularly the MSVC ecosystem is identified in TFA as being a late adopter. Once built c99 code can run where it wants.
  - Karellen 4y ago
    > Once built c99 code can run where it wants. Is that true on the MSVC ecosystem? Don't you have to compile separately for each `msvcrt` environment, as I thought they aren't binary compatible? And would a non-C99 msvcrt necessarily have an `snprintf()` implementation in its libc-equivalent dll?
    - cesarb 4y ago
      You can call code compiled with one msvcrXX from code compiled with a different msvcrXX, provided that you don't try passing things from one to the other (that is, no passing a pointer to a FILE structure, or even a file descriptor since the file descriptor table is on the msvcrXX instead of the kernel), and always free or realocate memory using the same msvcrXX (that is, don't allocate memory and expect your caller to call free() on it, always provide a custom deallocation function for your objects). This is possible because, unlike on Linux where function names are global, on Windows function names are scoped to the DLL, so you can have MSVCR71.DLL and MSVCR81.DLL loaded at the same time in the same process and they won't interfere with each other.
      - __alexs 4y ago
        > This is possible because, unlike on Linux where function names are global, on Windows function names are scoped to the DLL This is also possible on Linux with linker scripts AFAIK.
        rkeene2 4y ago
        Hmm, not really in the same way -- to do this with linker scripts you would need to rename some of the symbols in the library being consumed. What you can use, to a limited extent, is dlmopen(). Shared objects in Linux are just really late linked static objects, with fix-ups (hence PIC requirements). In macOS and Windows, there are heirarchies.
coldpie 4y ago
For systems programming, C89 is definitely a "sweet spot". It's relatively easy to write a compiler for and was dominant when system variety was at its highest, so it is best supported across the widest variety of platforms. Later C standards are harder to write compilers for and have questionable features like VLAs and more complicated macro syntax. C++ is a hideous mess. Rust is promising, and would probably be my choice personally, but it's also still fairly new and will limit your deployment platform options. C89 is still a reasonable choice today. I don't think it's depressing. It's a good language, and hitting the sweet spot of both language design and implementation is really hard, so you'd expect to have very few options.
- kibwen 4y ago
  Re: Rust, Curl is modular enough that you don't need to rewrite it in Rust in order to enjoy some of its benefits, you can just tell Curl to use Hyper (Rust's de-facto HTTP lib) as a backend. For the past few years they've been working on getting the Hyper backend to pass the Curl test suite and they're down to five remaining tests, so perfect support looks to be imminent: https://github.com/orgs/hyperium/projects/2/views/1 https://github.com/orgs/hyperium/projects/2/views/1 (seanmonstar occasionally streams on Twitch if you'd like to watch him work on these).
  - bitexploder 4y ago
    Also, and this sort of blows my mind, but Rust is almost 10 years old. It is a pretty darn stable language, especially for greenfield projects like a new HTTP library. The better Rust gets at interop the more it will begin to eat the systems programming world IMO, and we all benefit, even if it is quietly doing it without much fanfare.
    - laumars 4y ago
      I was with you right up until “quietly doing it without much fanfare”. Personal opinions of Rust aside, it has gained so much fanfare that “rewrite it Rust” is now practically a meme.
chrisseaton 4y ago
> If there were no advantages gained from C99, it wouldn't exist (people don't release language updates for no reason). Why isn't it possible that the updates aren't as good as the people who wrote them thought they were?
- pjmlp 4y ago
  VLA certainly were proven as a very bad idea, to the extent Google has paid the effort to remove all of it from the Linux kernel, as security measure.
  - uecker 4y ago
    As someone tangentially involved in this, I think this was misguided. But Linus also was not happy about code generation with VLAs.
    - tpush 4y ago
      > As someone tangentially involved in this, I think this was misguided. Do you mean the removal of VLAs from Linux? Why do you think that was misguided?
  - still_grokking 4y ago
    > VLA certainly were proven as a very bad idea VLAs aren't a problem. VLA in C are. But that's not because there is any issue with VLAs. The issue is that C concepts are stupid, but nobody fixes the roots of the issues. If you put something of variable length (a VLA) into something with limited static length (the "stack") it will explode. That's nothing new and nothing special or exclusive to VLAs. Actually, exactly this is one of the main issues with the bad C design since inception: It does not do bound checks (especially no static ones; as this would require proper depended typing for safe VLAs). Out of bound access will just "explode" as always in C (likely leaving a nice security crater). To be honest I don't get why we're still stuck with the stack / heap nonsense. There is not stack (or heap). There is only memory. What would be much more interesting would be direct control over the caches… Instead we still use the pure fantasy products "stack" and "heap" which are actually irrelevant (as they don't exist in the end). There is nothing "special" about "stack" memory. That's just a very primitive region based automatic memory allocator backed into the C runtime! The whole "using registers" thingy in context of "stack" is also just fake by now. You don't use HW registers—but some virtualization of them presented to you by the VM that runs inside the CPU. So you don't control register allocation anyway! So this could be made completely transparent without any impact. (The VM inside the CPU does the actual register allocation fully automatic. Presenting the "faked virtual ISA registers" to the outside world just to make "legacy" code happy).
sylware 4y ago
"people don't release language updates for no reason", indeed, many reasons are in the end "planned obsolescence" or ways to make even a naive compiler so much complex that only few remains, and of course in control of very few groups of ppl, and it is near impossible to implement reasonably a real life alternative. My opinion is C is already way too rich and complex. I would stick to c89 with benign bits of c99 and c11. The benchmark being "one average system developer coding a naive and real life C compiler in a reasonable amount of time and effort". That said, I know that my "next" C compiler will probably be a RISC-V assembler with a very conservative usage of a macro preprocessor.
ben0x539 4y ago
Writing curl today for your own use, on a platform/OS/tech stack you control, or to target all the places where curl runs right now? It's still deeply depressing how costly/impractical it is to apply improved technologies in the long tail of environments that isn't "linux on amd64" and similar, but it's not really a language design question in my opinion. We didn't get it "exactly right", we got it "good enough", and upgrade costs are prohibitively high for the general case.
nocman 4y ago
> If there were no advantages gained from C99, it wouldn't exist (people don't release language updates for no reason). That's not what the post said. He didn't say that C99 offered no advantages to anyone. He said no one could come up with benefits to the curl project that would be gained by moving to C99, therefore the risk introduced by doing so was not worth it for now (my paraphrase, obviously). It sounds to me like a perfectly good reason to stay with the current standard for that project. [edited to fix a typo]

sfpotter 4y ago

The requirements for writing curl are different from the requirements for writing other software. Just because C89 is a good choice for curl doesn't mean that C99 isn't a better choice for other things. The failure isn't in having revised a language, it's in thinking that all projects using the older version must upgrade. The idea that progress is linear is an illusion.

throwaway0x7E6 4y ago

some things actually just work

BiteCode_dev 4y ago

The question is more complicated than that: curl is so popular it is used on systems where c99 is not available. The question is how many of those exist, and are at which point it's not worth supporting them anymore.

UncleOxidant 4y ago
> curl is so popular it is used on systems where c99 is not available. What systems don't support a version gcc that compiles c99 at this point?
- BiteCode_dev 4y ago
  Old systems in ports and airports, military systems, anything that has a 50 years shelve life...
  - UncleOxidant 4y ago
    How many old systems like that are connected to the internet and could actually use curl?
    - nibbleshifter 4y ago
      Quite many!
    - BiteCode_dev 4y ago
      More than you would think, but curl is used to talk to the local network too, or inside VPN as well. Some hacks are quite crazy. E.G: there is this very old navy broacasting protocol, NMEA (https://en.wikipedia.org/wiki/NMEA_0183 https://en.wikipedia.org/wiki/NMEA_0183), that was designed so it could be transmitted through old fashion radio waves. You'll find it in some sonars, water sensors or AIS beacons. For this reason, despite that it looks more like a layer 4 protocol, it embeds its own packet format and checksum, all in ASCII, that clients are expected to parse. Now of course, a lot of devices are still emitting their data in NMEA, and it's not uncommon to be able to just telnet or netcat (if UDP) into one to see the data flowing. But after a while, people started to aggregate those data from their numerous sources into one single router, and expose this router for convenience through... HTTP over TCP/IP. And now you have those all those old computer towers (some still rocking a CRT screens or windows xp) doing long polling to get broadcasting data over a protocol that was made for request/reponse, to read the payload that is another protocol that was meant for radio equipment and hence requires manual consistency checks, that is transported by yet another protocol that is doing its best to preserve packets. And they say the spirit of hacking is dead :) (sometimes I feel IoT or domotic stacks look the same honestly) Of course, somewhere in there, there is a curl call. The question is therefore does curl author want to support a potential upgrade path for such twisted use case or not. I would say "nahhhh", but maybe curl had precisely the success it did because the author was ready to support it in crazy settings.
- deleted 4y ago
  [deleted]
bhawks 4y ago
Just a terminology rant: it is used in -builds- where c99 is not available. Particularly the MSVC ecosystem is identified in TFA as being a late adopter. Once built c99 code can run where it wants.
- Karellen 4y ago
  > Once built c99 code can run where it wants. Is that true on the MSVC ecosystem? Don't you have to compile separately for each `msvcrt` environment, as I thought they aren't binary compatible? And would a non-C99 msvcrt necessarily have an `snprintf()` implementation in its libc-equivalent dll?
  - cesarb 4y ago
    You can call code compiled with one msvcrXX from code compiled with a different msvcrXX, provided that you don't try passing things from one to the other (that is, no passing a pointer to a FILE structure, or even a file descriptor since the file descriptor table is on the msvcrXX instead of the kernel), and always free or realocate memory using the same msvcrXX (that is, don't allocate memory and expect your caller to call free() on it, always provide a custom deallocation function for your objects). This is possible because, unlike on Linux where function names are global, on Windows function names are scoped to the DLL, so you can have MSVCR71.DLL and MSVCR81.DLL loaded at the same time in the same process and they won't interfere with each other.
    - __alexs 4y ago
      > This is possible because, unlike on Linux where function names are global, on Windows function names are scoped to the DLL This is also possible on Linux with linker scripts AFAIK.
      - rkeene2 4y ago
        Hmm, not really in the same way -- to do this with linker scripts you would need to rename some of the symbols in the library being consumed. What you can use, to a limited extent, is dlmopen(). Shared objects in Linux are just really late linked static objects, with fix-ups (hence PIC requirements). In macOS and Windows, there are heirarchies.

coldpie 4y ago

For systems programming, C89 is definitely a "sweet spot". It's relatively easy to write a compiler for and was dominant when system variety was at its highest, so it is best supported across the widest variety of platforms. Later C standards are harder to write compilers for and have questionable features like VLAs and more complicated macro syntax. C++ is a hideous mess. Rust is promising, and would probably be my choice personally, but it's also still fairly new and will limit your deployment platform options. C89 is still a reasonable choice today. I don't think it's depressing. It's a good language, and hitting the sweet spot of both language design and implementation is really hard, so you'd expect to have very few options.

kibwen 4y ago
Re: Rust, Curl is modular enough that you don't need to rewrite it in Rust in order to enjoy some of its benefits, you can just tell Curl to use Hyper (Rust's de-facto HTTP lib) as a backend. For the past few years they've been working on getting the Hyper backend to pass the Curl test suite and they're down to five remaining tests, so perfect support looks to be imminent: https://github.com/orgs/hyperium/projects/2/views/1 https://github.com/orgs/hyperium/projects/2/views/1 (seanmonstar occasionally streams on Twitch if you'd like to watch him work on these).
- bitexploder 4y ago
  Also, and this sort of blows my mind, but Rust is almost 10 years old. It is a pretty darn stable language, especially for greenfield projects like a new HTTP library. The better Rust gets at interop the more it will begin to eat the systems programming world IMO, and we all benefit, even if it is quietly doing it without much fanfare.
  - laumars 4y ago
    I was with you right up until “quietly doing it without much fanfare”. Personal opinions of Rust aside, it has gained so much fanfare that “rewrite it Rust” is now practically a meme.

chrisseaton 4y ago

> If there were no advantages gained from C99, it wouldn't exist (people don't release language updates for no reason). Why isn't it possible that the updates aren't as good as the people who wrote them thought they were?

pjmlp 4y ago
VLA certainly were proven as a very bad idea, to the extent Google has paid the effort to remove all of it from the Linux kernel, as security measure.
- uecker 4y ago
  As someone tangentially involved in this, I think this was misguided. But Linus also was not happy about code generation with VLAs.
  - tpush 4y ago
    > As someone tangentially involved in this, I think this was misguided. Do you mean the removal of VLAs from Linux? Why do you think that was misguided?
- still_grokking 4y ago
  > VLA certainly were proven as a very bad idea VLAs aren't a problem. VLA in C are. But that's not because there is any issue with VLAs. The issue is that C concepts are stupid, but nobody fixes the roots of the issues. If you put something of variable length (a VLA) into something with limited static length (the "stack") it will explode. That's nothing new and nothing special or exclusive to VLAs. Actually, exactly this is one of the main issues with the bad C design since inception: It does not do bound checks (especially no static ones; as this would require proper depended typing for safe VLAs). Out of bound access will just "explode" as always in C (likely leaving a nice security crater). To be honest I don't get why we're still stuck with the stack / heap nonsense. There is not stack (or heap). There is only memory. What would be much more interesting would be direct control over the caches… Instead we still use the pure fantasy products "stack" and "heap" which are actually irrelevant (as they don't exist in the end). There is nothing "special" about "stack" memory. That's just a very primitive region based automatic memory allocator backed into the C runtime! The whole "using registers" thingy in context of "stack" is also just fake by now. You don't use HW registers—but some virtualization of them presented to you by the VM that runs inside the CPU. So you don't control register allocation anyway! So this could be made completely transparent without any impact. (The VM inside the CPU does the actual register allocation fully automatic. Presenting the "faked virtual ISA registers" to the outside world just to make "legacy" code happy).

sylware 4y ago

"people don't release language updates for no reason", indeed, many reasons are in the end "planned obsolescence" or ways to make even a naive compiler so much complex that only few remains, and of course in control of very few groups of ppl, and it is near impossible to implement reasonably a real life alternative. My opinion is C is already way too rich and complex. I would stick to c89 with benign bits of c99 and c11. The benchmark being "one average system developer coding a naive and real life C compiler in a reasonable amount of time and effort". That said, I know that my "next" C compiler will probably be a RISC-V assembler with a very conservative usage of a macro preprocessor.

ben0x539 4y ago

Writing curl today for your own use, on a platform/OS/tech stack you control, or to target all the places where curl runs right now? It's still deeply depressing how costly/impractical it is to apply improved technologies in the long tail of environments that isn't "linux on amd64" and similar, but it's not really a language design question in my opinion. We didn't get it "exactly right", we got it "good enough", and upgrade costs are prohibitively high for the general case.

nocman 4y ago

> If there were no advantages gained from C99, it wouldn't exist (people don't release language updates for no reason). That's not what the post said. He didn't say that C99 offered no advantages to anyone. He said no one could come up with benefits to the curl project that would be gained by moving to C99, therefore the risk introduced by doing so was not worth it for now (my paraphrase, obviously). It sounds to me like a perfectly good reason to stay with the current standard for that project. [edited to fix a typo]