One of my pet-peeves with C projects is that it's so often more or less "works on my machine" when written by Linux users (as a Windows and FreeBSD user it often hits you on both those platforms).
The article highlights a typical piece:
#if !(defined __GNUC__ || defined __clang__ || defined __TINYC__)
# define __attribute__(xyz) /* Ignore */
#endif
There is no reason that !defined check to not include a check for __attribute__ already being defined (a custom compiler author could then force an define for __attribute__ that translates to an internal __mycompiler__attribute__ replacement by default).
But outside of that, just trying to compile on FreeBSD you often run into systemd dependencies or other non-posix behaviors (Not to mention on Windows but I'm not here to bring on flamewars so I'll leave that part).
MSVC support for C is fairly terrible. For the projects we write that are portable to Windows we insist you use GCC or Clang on Windows. No one has time to deal with the lack of even standard C1x/C2x features (never mind useful extensions like attribute cleanup).
Surprised about FreeBSD. My experience is that porting Linux software is usually pretty easy as long as it's not using some Linux-only feature (io_uring for instance).
systemd is indeed the bane of Linux, and a pain in the ass for a lot of FOSS. Once the main distributions made it mandatory to install (not just the default, but mandatory) - we've started to see this sort of bifrucation of a lot more FOSS away from being standard-based and multi-platform to being Linux-specific.
That said - I think a rule-of-thumb one can follow is that any inclusion of a file with a directory prefix, especially `<sys/whatever>`, needs a guarantee-of-availability in your build configuration phase, e.g. CMake `find_package()`, or or at least `check_include_file()` and such. That way, you might be more likely to fail to build, but at least you'll be telling the user "I expect these things to be present".
The preceding comment indicates that the intent is to support other compilers. I think a better approach is to define __glibc_attribute__ based on compiler support and to stick to that within glibc since there's no reason to think that another compiler's attributes have the same semantics as GNU C's.
If it is an open source project then that is quite alright with me. An open source author doesn't need to support all platforms. Only those they care about. If someone else wants support for another platform they have the source.
For a bunch of software categories there isn't really much point to support Windows at all these days. We've had "developed for unix, ported to Windows" software for a long time and it often doesn't work that well, because the agreement even for fairly basic stuff is not that large between the two.
1: My point isn't "developer on unix, ported to Windows", it's "developed on linux, maybe works elsewhere".
2: You could easily compile Samba yourself for FreeBSD in the past, last time I tried a new version it broke in what I remember being due to linux-isms (yes there is ports, but being reliant on older versions if ports maintainers can't keep up isn't a good thing).
3: The only "fairly basic" stuff that's hugely different is mostly the absence/reliance on shell-scripts (when building), but that has little to do with the actual code function (Personally I often used Node scripts in those scenarios, Python scripts would probably be an improvement since there's no reason it couldn't be everywhere).
I used to use Tremor to decode Ogg audio (no UI needs, just binary data in, arrays of primitive values in audio buffers out), early versions were easy to compile under Windows but building later versions were buried in shell scripts generating headers,etc for no real good reason (maybe to help port when working on a Linux workstation to other embedded devices but made the code less easily compilable by default), the core functionality only really needed a C compiler as early versions showed.
I can agree that something with advanced UI's like Blender (that relies on GL/3d rendering for UI) might not be easily portable, but when algortihm libraries often requires heavy reworking it's not a good thing (Here I think Github has helped since people has had an easier time to contribute, it's a sad thing that people are moving away due to the AI-crap).
In the end, it's not about _actual_ differences but more of a superiority complex of Linux users that is the main roadblock.
Exactly, the amount of patches needed in many FreeBSD or other BSD ports just to appease the Linux-centricity is bonkers. And many times the changes aren't even that grave.
There's portability between systems, which as you note, has ever-diminishing returns.
Then there's portability between compilers, which, as the article notes, glibc is also completely hostile to (except for anointed compilers) for no good reason whatsoever.
Yes, when I implemented ImportC (a C compiler built in to the D compiler), I had to spend a lot of time finding ways to work with all the nutburger nonsense in the various .h files.
I have no knowledge of this specific "why", but my general experience shows that feature flags, while almost universally better than checks for the specific software version in hope that it has proper support for a feature, appear only as a replacement to platform / software detection, after a few years of struggle.
It's probably just natural for software developers (myself included), whenever only FooZoid v5 supports frobnicate(), say "#ifdef FOOZOID_V5" and go back to your business, rather than introducing "FROBNICATE_SUPPORTED".
Also, when you try to ask for a feature flag in the code review, people will throw YAGNI at you, and they might be not wrong, at least for the first few years. After that, it's a costly refactor.
For those who are making indie C compilers that don't pretend to be __GNUC__ but want to compile real world projects, slimcc's test script[1] and platform header hacks[2] might save you some time.
[1] https://github.com/fuhsnn/slimcc/blob/main/scripts/linux_thi...
- Game projects default to using SIMD so for example SDL and STB you always need to pass -DSDL_DISABLE_IMMINTRIN_H and -DSTB_NO_SIMD
- math.h's NAN usually fall back to (0.0f / 0.0f), which will print "-nan" with printf, some projects test suite fail because of it (they expected "nan").
- NetBSD's sys/cdefs.h straight up #error's if you don't pretend to be GCC or PCC.
- Some projects can't compile without __attribute__((always_inline)) because they use it on non-static functions.
- Many projects probe -fvisibility in the build system and pass -fvisibility=hidden to compile, but in the headers they gate __attribute__((visibility(default))) behind __GNUC__ checks, so you'll get missing symbols.
- Some projects use if(0) { undefined_function() } to fake static_assert(), there is even a bug report from QEMU to Clang because it failed to optimize in -O0 a certain `if` written this way.
- Even if you define __STDC_NO_VLA__, projects might fall back to alloca() code path that's untested and broken (python and jemalloc both had this problem, already reported)
- Valkey has broken __builtin_ctzll fallback nobody noticed (reported).
- Zig's C bootstrap path expects the compiler to have GCC/Clang-tier optimization and stack overflows if you don't (reported).
- I contributed stdatomic.h code path for Ruby just to compile it with slimcc, pretty sure it's still the only user of the code path.
- I implemented __has_extension in the hope that projects can use it to query gnu_asm; but SQLite broke because they use __has_extension(c_atomic) to query GNU atomics builtin, but c_atomic actually is meant for C11 _Atomic (IMO they should use __has_builtin)
I just implemented a fast small compiler rcc to compete against tcc, and these glibc header quirks were simply fixed in the same way clang does it. By defining all gcc predefines and implementing all gcc extensions. Needed a day. And my headers are clean compared to glibc. The others in this league are slimcc, kefir and cproc. No other compilers can parse glibc headers. tcc has this special exception.
Back in my youth I implemented a C compiler that was almost impressive.
Dealing with the preprocessor (essentially a different, crippled language) was too much headache at the start so I just used `cpp`, and at the end, I was just too lazy to implement it, so continued using `cpp`.
(BTW: Anyone else here ever used the Cosmic C Compiler for Motorola microcontrollers? Amongst other idiosyncrasies, it had only one datatype - `byte` - and I had to implement macros to do 16-bit arithmetic operations. That project was easily the worst development experience of my life.)
One approach for testing with multiple compilers that I use on some Fortran projects (where testing against multiple compilers seems more common than in C) is to use a variable from the command line to specify the compiler, for example:
make FC=ifx check
On my Fortran projects, that will run the tests with Intel's Fortran compiler. The Makefile has logic to automatically change compiler flags as appropriate. I default to the GNU Fortran compiler, so `FC` isn't required.
I have made a script to run through a series of compilers by alternating between `make check` and `make clean`.
I have separate Makefiles for GNU Make and NMAKE/jom. My Fortran code works fine on various Linux distributions and Windows, though I'll add that achieving that is probably easier with Fortran than C. I've also tried a BSD Make that worked (on Ubuntu at least). My Makefiles are pretty close to the intersection of POSIX and NMAKE, so the main differences between the different Make versions are the conditional statements needed to handle the different compiler flags and the include statements (as I put the compiler flags in separate files).
Realistically, you don't aim to support every platform. You have a finite set of platforms you want to support. As the size of that set goes up, so does the probability it'll work on platforms unknown to you, but it's never 100%. Did you know some platforms have 32-bit char?
One of my pet-peeves with C projects is that it's so often more or less "works on my machine" when written by Linux users (as a Windows and FreeBSD user it often hits you on both those platforms).
The article highlights a typical piece:
There is no reason that !defined check to not include a check for __attribute__ already being defined (a custom compiler author could then force an define for __attribute__ that translates to an internal __mycompiler__attribute__ replacement by default).But outside of that, just trying to compile on FreeBSD you often run into systemd dependencies or other non-posix behaviors (Not to mention on Windows but I'm not here to bring on flamewars so I'll leave that part).
MSVC support for C is fairly terrible. For the projects we write that are portable to Windows we insist you use GCC or Clang on Windows. No one has time to deal with the lack of even standard C1x/C2x features (never mind useful extensions like attribute cleanup).
Surprised about FreeBSD. My experience is that porting Linux software is usually pretty easy as long as it's not using some Linux-only feature (io_uring for instance).
systemd is indeed the bane of Linux, and a pain in the ass for a lot of FOSS. Once the main distributions made it mandatory to install (not just the default, but mandatory) - we've started to see this sort of bifrucation of a lot more FOSS away from being standard-based and multi-platform to being Linux-specific.
That said - I think a rule-of-thumb one can follow is that any inclusion of a file with a directory prefix, especially `<sys/whatever>`, needs a guarantee-of-availability in your build configuration phase, e.g. CMake `find_package()`, or or at least `check_include_file()` and such. That way, you might be more likely to fail to build, but at least you'll be telling the user "I expect these things to be present".
>One of my pet-peeves with C projects is that it's so often more or less "works on my machine"
“All the world's a VAX”
https://groups.google.com/g/comp.lang.c/c/CYgWkWdWCcQ/m/thMt...
https://www.lysator.liu.se/c/ten-commandments.html
The preceding comment indicates that the intent is to support other compilers. I think a better approach is to define __glibc_attribute__ based on compiler support and to stick to that within glibc since there's no reason to think that another compiler's attributes have the same semantics as GNU C's.
If it is an open source project then that is quite alright with me. An open source author doesn't need to support all platforms. Only those they care about. If someone else wants support for another platform they have the source.
For a bunch of software categories there isn't really much point to support Windows at all these days. We've had "developed for unix, ported to Windows" software for a long time and it often doesn't work that well, because the agreement even for fairly basic stuff is not that large between the two.
1: My point isn't "developer on unix, ported to Windows", it's "developed on linux, maybe works elsewhere".
2: You could easily compile Samba yourself for FreeBSD in the past, last time I tried a new version it broke in what I remember being due to linux-isms (yes there is ports, but being reliant on older versions if ports maintainers can't keep up isn't a good thing).
3: The only "fairly basic" stuff that's hugely different is mostly the absence/reliance on shell-scripts (when building), but that has little to do with the actual code function (Personally I often used Node scripts in those scenarios, Python scripts would probably be an improvement since there's no reason it couldn't be everywhere).
I used to use Tremor to decode Ogg audio (no UI needs, just binary data in, arrays of primitive values in audio buffers out), early versions were easy to compile under Windows but building later versions were buried in shell scripts generating headers,etc for no real good reason (maybe to help port when working on a Linux workstation to other embedded devices but made the code less easily compilable by default), the core functionality only really needed a C compiler as early versions showed.
I can agree that something with advanced UI's like Blender (that relies on GL/3d rendering for UI) might not be easily portable, but when algortihm libraries often requires heavy reworking it's not a good thing (Here I think Github has helped since people has had an easier time to contribute, it's a sad thing that people are moving away due to the AI-crap).
In the end, it's not about _actual_ differences but more of a superiority complex of Linux users that is the main roadblock.
Exactly, the amount of patches needed in many FreeBSD or other BSD ports just to appease the Linux-centricity is bonkers. And many times the changes aren't even that grave.
There's portability between systems, which as you note, has ever-diminishing returns.
Then there's portability between compilers, which, as the article notes, glibc is also completely hostile to (except for anointed compilers) for no good reason whatsoever.
Yes, when I implemented ImportC (a C compiler built in to the D compiler), I had to spend a lot of time finding ways to work with all the nutburger nonsense in the various .h files.
https://github.com/dlang/dmd/blob/master/druntime/src/import...
https://github.com/dlang/dmd/blob/master/druntime/src/__impo...
Why would they not do something like?
(or probably a more fine grained for each attribute they try to use)Considering such checks are fairly conventional in downstream C++ libraries based on compilers (for example checking OS platform or compiler, e.g. [Boost.Config](https://www.boost.org/doc/libs/latest/libs/config/). Modern C++ even went ahead and standardized this somewhat https://en.cppreference.com/cpp/utility/feature_test )
I have no knowledge of this specific "why", but my general experience shows that feature flags, while almost universally better than checks for the specific software version in hope that it has proper support for a feature, appear only as a replacement to platform / software detection, after a few years of struggle.
It's probably just natural for software developers (myself included), whenever only FooZoid v5 supports frobnicate(), say "#ifdef FOOZOID_V5" and go back to your business, rather than introducing "FROBNICATE_SUPPORTED".
Also, when you try to ask for a feature flag in the code review, people will throw YAGNI at you, and they might be not wrong, at least for the first few years. After that, it's a costly refactor.
For those who are making indie C compilers that don't pretend to be __GNUC__ but want to compile real world projects, slimcc's test script[1] and platform header hacks[2] might save you some time. [1] https://github.com/fuhsnn/slimcc/blob/main/scripts/linux_thi...
[2] https://github.com/fuhsnn/slimcc/blob/main/slimcc_headers/pl...
Some more fun stories:
- Game projects default to using SIMD so for example SDL and STB you always need to pass -DSDL_DISABLE_IMMINTRIN_H and -DSTB_NO_SIMD
- math.h's NAN usually fall back to (0.0f / 0.0f), which will print "-nan" with printf, some projects test suite fail because of it (they expected "nan").
- NetBSD's sys/cdefs.h straight up #error's if you don't pretend to be GCC or PCC.
- Some projects can't compile without __attribute__((always_inline)) because they use it on non-static functions.
- Many projects probe -fvisibility in the build system and pass -fvisibility=hidden to compile, but in the headers they gate __attribute__((visibility(default))) behind __GNUC__ checks, so you'll get missing symbols.
- Some projects use if(0) { undefined_function() } to fake static_assert(), there is even a bug report from QEMU to Clang because it failed to optimize in -O0 a certain `if` written this way.
- Even if you define __STDC_NO_VLA__, projects might fall back to alloca() code path that's untested and broken (python and jemalloc both had this problem, already reported)
- Valkey has broken __builtin_ctzll fallback nobody noticed (reported).
- Zig's C bootstrap path expects the compiler to have GCC/Clang-tier optimization and stack overflows if you don't (reported).
- I contributed stdatomic.h code path for Ruby just to compile it with slimcc, pretty sure it's still the only user of the code path.
- I implemented __has_extension in the hope that projects can use it to query gnu_asm; but SQLite broke because they use __has_extension(c_atomic) to query GNU atomics builtin, but c_atomic actually is meant for C11 _Atomic (IMO they should use __has_builtin)
I just implemented a fast small compiler rcc to compete against tcc, and these glibc header quirks were simply fixed in the same way clang does it. By defining all gcc predefines and implementing all gcc extensions. Needed a day. And my headers are clean compared to glibc. The others in this league are slimcc, kefir and cproc. No other compilers can parse glibc headers. tcc has this special exception.
Back in my youth I implemented a C compiler that was almost impressive.
Dealing with the preprocessor (essentially a different, crippled language) was too much headache at the start so I just used `cpp`, and at the end, I was just too lazy to implement it, so continued using `cpp`.
(BTW: Anyone else here ever used the Cosmic C Compiler for Motorola microcontrollers? Amongst other idiosyncrasies, it had only one datatype - `byte` - and I had to implement macros to do 16-bit arithmetic operations. That project was easily the worst development experience of my life.)
What is the feasible way to test code against the matrix of compilers/oses?
One approach for testing with multiple compilers that I use on some Fortran projects (where testing against multiple compilers seems more common than in C) is to use a variable from the command line to specify the compiler, for example:
On my Fortran projects, that will run the tests with Intel's Fortran compiler. The Makefile has logic to automatically change compiler flags as appropriate. I default to the GNU Fortran compiler, so `FC` isn't required.I have made a script to run through a series of compilers by alternating between `make check` and `make clean`.
I have separate Makefiles for GNU Make and NMAKE/jom. My Fortran code works fine on various Linux distributions and Windows, though I'll add that achieving that is probably easier with Fortran than C. I've also tried a BSD Make that worked (on Ubuntu at least). My Makefiles are pretty close to the intersection of POSIX and NMAKE, so the main differences between the different Make versions are the conditional statements needed to handle the different compiler flags and the include statements (as I put the compiler flags in separate files).
Realistically, you don't aim to support every platform. You have a finite set of platforms you want to support. As the size of that set goes up, so does the probability it'll work on platforms unknown to you, but it's never 100%. Did you know some platforms have 32-bit char?
And architectures. Probably a bunch of build servers or a swarm of docker, qemu, and VMs, with a good test coverage to detect behaviour differences.
In practice, the compiler is an often an omitted dependency of any c code.
I think I did not get to that level yet where I trust Claude to create its own VMs. But one day I will.