6 ms·

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 ar

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.
      - still_grokking 4y ago
        But couldn't you just cross compile to such targets? I think nobody really does any serous development on such old machines.
        BiteCode_dev 4y ago
        Maybe. Or maybe they have the only know toolchain to work installed on this single machine somewhere in the basement (seen in a healthcare corp), or they have a chain of trust that needs way too much effort to verify again (seen in the army), or they are not comptent enough to do such thing (seen in airports), or their whole stack is so old it can only run on this stuff (seen in ports), or their target is exotic and you can't cross compile to it easily (seen in aerospace). Again, not sure that it means curl should endorse such niche situations, but the modes of failure are numerous. TL;DR: the world is complicated
        still_grokking 4y ago
        I read this as: If there would be real need in almost all cases you could cross compile (the exotic target being the exception). Whether this is feasible in a economic sense is another question. But technical it should be possible.
    - deleted 4y ago
      [deleted]
- 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.

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.
    - still_grokking 4y ago
      But couldn't you just cross compile to such targets? I think nobody really does any serous development on such old machines.
      - BiteCode_dev 4y ago
        Maybe. Or maybe they have the only know toolchain to work installed on this single machine somewhere in the basement (seen in a healthcare corp), or they have a chain of trust that needs way too much effort to verify again (seen in the army), or they are not comptent enough to do such thing (seen in airports), or their whole stack is so old it can only run on this stuff (seen in ports), or their target is exotic and you can't cross compile to it easily (seen in aerospace). Again, not sure that it means curl should endorse such niche situations, but the modes of failure are numerous. TL;DR: the world is complicated
        still_grokking 4y ago
        I read this as: If there would be real need in almost all cases you could cross compile (the exotic target being the exception). Whether this is feasible in a economic sense is another question. But technical it should be possible.
  - deleted 4y ago
    [deleted]
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.