4 ms·

Windows is what annoys me about C's portability story. C prides itself on supporting every platform, including exotic and dead ones, but only hypothetically. Th

by pornel 5y ago

Windows is what annoys me about C's portability story. C prides itself on supporting every platform, including exotic and dead ones, but only hypothetically. The spec is all about the potential. All the portability promises end the moment you try to compile anything. It doesn't work, but that is no longer C's problem. It's simultaneously the most portable language in the world, and one that barely works on the most popular desktop OS.

ziml77 5y ago
I wonder if people would still call C portable if there were more non-POSIX-compliant operating systems
- flohofwoe 5y ago
  The ANSI/ISO C standard library and the POSIX standard are two different things though that just happen to overlap here and there.
  - ziml77 5y ago
    My point is that a lot of people treat the POSIX standard as if it was the C standard library. It's understandable because of how limited the actual standard library is, but it leads to people having a view that an OS is doing things wrong if it's not following POSIX.
    - dundarious 5y ago
      I think the proliferation of POSIX-like OSes is mostly down to OS projects wanting there to be useful software that can run on their OS, so they minimize/eliminate the work of porting. It has led to the phenomenon you describe though -- instead of thinking an OS is just too much work to port to, it might be thought of as being "wrong".
    - pjmlp 5y ago
      Worse is when the OS does follow POSIX but people haven't read the fine print that certain POSIX APIs are implementation dependent, e.g. signal handling and threads.
- pjmlp 5y ago
  There are plenty of them, the FOSS culture just tends to ignore them.
- vbezhenar 5y ago
  Microcontrollers usually are not POSIX-compliant. Android and iOS are not POSIX-complaint.
flohofwoe 5y ago
"C the language" is very portable and useful, "C the standard runtime library" much less so because it's essentially stuck in the 80's. Good for very simple UNIX-style command line tools, but not much else. But for non-trivial projects that's not much of a problem because it's quite trivial to ignore the C stdlib functions and call directly into OS APIs (via your own or 3rd-party cross-platform libraries).
- jstimpfle 5y ago
  Yup, and to complement, a very important technique is to design platform-specific layers such that they call the (portable) application code - not the other way around. The more typical approach is attempting to find abstractions for I/O and other platform specific facilities that can be implemented by all targeted platforms. The issue with that is that it is very hard to really make use of the platform this way, or even implement all abstractions for all platforms without quirks. If instead the platform layer calls the (un-abstracted) portable application code, there is no code that needs to be pushed through misfitting abstractions. I learned this approach from Handmade Here / Handmade Community and it's probably the deepest architectural lesson I learned anywhere, while it seems to be not widely known. I'm almost tempted to say that the conventional approach is wrong and misguided. However, an issue with the platform-calls-code approach is that the code usually can only communicate asynchronously with the platform (one of the issues with code-calls-platform is the one-shot synchronous nature of function calls). That might not work always, for example, I wanted RDTSC counters or Copy-Paste functionality, and I still do this by finding a platform abstraction that the code can call into directly.
  - dundarious 5y ago
    I know RDTSC was just an example, but I really wouldn't worry about going Platform->App->Platform for features that have no architectural concerns or impact (in this case, some number connected to performance, probably a cycle count, that's monotonically increasing). I/O would be the major no-no.
    - jstimpfle 5y ago

by pornel 5y ago

ziml77 5y ago

I wonder if people would still call C portable if there were more non-POSIX-compliant operating systems

flohofwoe 5y ago
The ANSI/ISO C standard library and the POSIX standard are two different things though that just happen to overlap here and there.
- ziml77 5y ago
  My point is that a lot of people treat the POSIX standard as if it was the C standard library. It's understandable because of how limited the actual standard library is, but it leads to people having a view that an OS is doing things wrong if it's not following POSIX.
  - dundarious 5y ago
    I think the proliferation of POSIX-like OSes is mostly down to OS projects wanting there to be useful software that can run on their OS, so they minimize/eliminate the work of porting. It has led to the phenomenon you describe though -- instead of thinking an OS is just too much work to port to, it might be thought of as being "wrong".
  - pjmlp 5y ago
    Worse is when the OS does follow POSIX but people haven't read the fine print that certain POSIX APIs are implementation dependent, e.g. signal handling and threads.
pjmlp 5y ago
There are plenty of them, the FOSS culture just tends to ignore them.
vbezhenar 5y ago
Microcontrollers usually are not POSIX-compliant. Android and iOS are not POSIX-complaint.

flohofwoe 5y ago

"C the language" is very portable and useful, "C the standard runtime library" much less so because it's essentially stuck in the 80's. Good for very simple UNIX-style command line tools, but not much else. But for non-trivial projects that's not much of a problem because it's quite trivial to ignore the C stdlib functions and call directly into OS APIs (via your own or 3rd-party cross-platform libraries).

jstimpfle 5y ago
Yup, and to complement, a very important technique is to design platform-specific layers such that they call the (portable) application code - not the other way around. The more typical approach is attempting to find abstractions for I/O and other platform specific facilities that can be implemented by all targeted platforms. The issue with that is that it is very hard to really make use of the platform this way, or even implement all abstractions for all platforms without quirks. If instead the platform layer calls the (un-abstracted) portable application code, there is no code that needs to be pushed through misfitting abstractions. I learned this approach from Handmade Here / Handmade Community and it's probably the deepest architectural lesson I learned anywhere, while it seems to be not widely known. I'm almost tempted to say that the conventional approach is wrong and misguided. However, an issue with the platform-calls-code approach is that the code usually can only communicate asynchronously with the platform (one of the issues with code-calls-platform is the one-shot synchronous nature of function calls). That might not work always, for example, I wanted RDTSC counters or Copy-Paste functionality, and I still do this by finding a platform abstraction that the code can call into directly.
- dundarious 5y ago
  I know RDTSC was just an example, but I really wouldn't worry about going Platform->App->Platform for features that have no architectural concerns or impact (in this case, some number connected to performance, probably a cycle count, that's monotonically increasing). I/O would be the major no-no.
  - jstimpfle 5y ago