5 ms·

C extensions, portability, and alternative compilers

175 points by xngbuilds 4mo ago

whizzter 4mo ago
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).
- formerly_proven 4mo ago
  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.
  - zephen 4mo ago
    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.
    - account42 4mo ago
      > which, as the article notes, glibc is also completely hostile to This is neither true nor claimed by the article.
      - zephen 4mo ago
        The article specifically states "If you aren't gcc, clang, or tcc, tough luck." It doesn't work. For no good reason. Because there are a few anointed compilers. That it wasn't on purpose doesn't make it not hostile.
  - deleted 4mo ago
    [deleted]
  - jdw64 4mo ago
    in Asia, and over here, Windows is the de facto standard while Linux is actually a poor option. Almost all of the infrastructure is written for Windows, so the second you switch to Linux, you're fighting an uphill battle just to do basic tasks. Seeing this makes you realize that our worldview is entirely shaped by the ecosystem we live in
  - whizzter 4mo ago
    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.
    - rootnod3 4mo ago
      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.
    - matheusmoreira 4mo ago
      Superiority complex? How many times have we been told that we're entitled freeloaders for expecting Linux compatibility work from others? Insulted by people who use dominant platforms that get all the commercial support while we get literally nothing? Reduced to reverse engineering stuff with no documentation and zero help? Pretty wild to watch this unfold. Now that Linux is finally coming out ahead, as it should, because people are finally writing software for it... Suddenly we're the bullies.
- BadBadJellyBean 4mo ago
  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.
  - whizzter 4mo ago
    Yeah, I think I did miss mentioning that my comment was more weighted on simpler cli tools or library projects (file format readers,etc). I don't expect anyone writing GUI tools or more high-perf servers to spend their time porting to other platforms (trying to compile GTK on Windows wasn't for the faint of heart).
- kps 4mo ago
  >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/thMt3RfByAgJ?pli=1 https://groups.google.com/g/comp.lang.c/c/CYgWkWdWCcQ/m/thMt... https://www.lysator.liu.se/c/ten-commandments.html https://www.lysator.liu.se/c/ten-commandments.html
- dooglius 4mo ago
  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.
  - rurban 4mo ago
    That ship sailed already. You simply have to mimic gcc. Which is at least better than with MSVC, where they did everything differently, and only half of it.
    - account42 4mo ago
      Well in practice you have to mimic GCC except for Windows where you have to mimic MSVC.
      - rurban 4mo ago
        Not really. MSVC is too broken. I just mimic x86_64-w64-mingw32-gcc, which exists everywhere.
- rwmj 4mo ago
  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).
  - jstimpfle 4mo ago
    What do you even miss, honestly works fine for me? In terms of platform APIs, I prefer the Windows ones on Windows anyway
    - drwu 4mo ago
      Complex numbers, for example. Also, C preprocessor expands macros differently on MSVC.
      - david2ndaccount 4mo ago
        Use the new standards-conformant preprocessor with `/Zc:preprocessor` https://learn.microsoft.com/en-us/cpp/build/reference/zc-preprocessor?view=msvc-170 https://learn.microsoft.com/en-us/cpp/build/reference/zc-pre...
      - jstimpfle 4mo ago
        Wasn't aware of preprocessor conformity issues, good to know!
  - bigbadfeline 4mo ago
    > 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). I'm not sure why you're surprised, the parent of you comment clearly stated "on FreeBSD you often run into systemd dependencies or other non-posix behaviors" which means, software written for Linux often uses "Linux-only features" such as systemd and other non-posix dependencies that are foreign to the BSDs and traditional UNIX. Thus, it shouldn't be surprising that Linux software is hard to port to the BSDs. Linux used to be a pretty good UNIX, I'm not sure what it is now.
- einpoklum 4mo ago
  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".
  - jeltz 4mo ago
    No, systemd is not the bane of Linux. What existed before it was much worse. Upstart was a totally broken mess and almost all sysv init scripts contained several bugs. I don't like systemd but it is a lesser evil.
    - einpoklum 4mo ago
      systemd is not an init system; it _contains_ an init system. It is a huge swatch of the whole userspace of a Linux system up to shell or GUI sessions - and having an init system was just an excuse; and in fact, the systemd point brought up in the linked article is unrelated to init systems. There are quite a few init systems: The venerable sysvinit, runit, s6, openrc and others. You don't like upstart? Ok, choose another one, there are many. Here is a comparison table by the Gentoo folks: https://wiki.gentoo.org/wiki/Comparison_of_init_systems https://wiki.gentoo.org/wiki/Comparison_of_init_systems As for the claim of "almost all sysvinit scripts contained several bugs" - that's both hyperbole and false. Plus, you seem to be implying that systemd has not been troubled by bugs, which of course it has (and that does not disqualify it; the fundamental design and organizational nature as a project are the disqualifiers).
      - cestith 4mo ago
        The systemd init system is quite the Trojan horse, though. I prefer it greatly to SystemV init. Most of the rest of systemd varies from unremarkable to problematic in my opinion. One bright spot is systemd-networkd allows one to change quite a few things about interfaces in the way server automation platforms expect to work without doing a network restart. The workaround otherwise on, say, CentOS was always to write the new config file used by future restarts, also run CLI commands to update things in memory, and be sure to tell the service not to trigger a restart on the config file(s) changing. Otherwise if you’re doing something like streaming UDP video your own automation can become a reliability issue.
- matheusmoreira 4mo ago
  > 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). Windows users singling out Linux users for not catering to their platform. How the times change... > you often run into systemd dependencies or other non-posix behaviors Not a problem. POSIX is irrelevant, systemd is great and we should all be using Linux to its fullest extent. Linux has great features and there is absolutely no reason not to use them all. Nobody complains about the fact BSDs have cool things like kqueue and unveil.
  - neonz80 4mo ago
    > Windows users singling out Linux users for not catering to their platform. How the times change... In my experience this was a problem over 25 years ago when I developed for Solaris and other non-Linux operating systems.
    - benj111 4mo ago
      I think I may(?) have got into Linux 20+ years ago when I was trying to learn c and even the basic Hello World wouldn't work for me. So I suppose it does have a marketing benefit in that I now use Linux.
  - whizzter 4mo ago
    > Windows users singling out Linux users for not catering to their platform. How the times change... This goes back to the days I was browsing freshmeat and saw some interesting command line tool or otherwise non-UI tool from some hopeful developer for something useful. Node had significant traction but didn't really blow up until it became really cross-platform. And perhaps is less of an issue these days since so many people use Mac's as their primary, so less Linux-isms survive once in context with osX. > Not a problem. POSIX is irrelevant, systemd is great and we should all be using Linux to its fullest extent. Linux has great features and there is absolutely no reason not to use them all. Nobody complains about the fact BSDs have cool things like kqueue and unveil. From following it over the year it was not entirely welcomed even in the linux community (and some of the security issues made one shudder). Mostly it's the monolithic nature that's makes it a questionable, is it Gnu/Linux these days or Systemd/Linux ? kqueue is just an api, just like epoll, io_uring or even iocp on windows. And yes, it's a special case for high-perf servers where posix becomes less relevant (and while I can appreciate some lower-perf fallback to be able to develop/port to another platform like a console I do see that some programs are inherently platform bound). I think one thing lost in my original comment was that I was often encountering things like this with "simple" CLI tools or lower level format libraries, and honestly projects like that also had a tendency to break over time without updates as they often relied on specific versions of libraries the maintainers had installed via Linux package managers, in the same fashion as npm has caused churn in the JS community. (npm at least has version pinning so old cli tools can often be run as long as node hasn't deprecated api's).
- dgrunwald 4mo ago
  In our compiler (in a code analysis tool), we have #pragma immutable_macro __attribute__ After this pragma, any attempt to #define/#undef the macro "__attribute__" will be silently ignored. This lets us (or our customers) bypass such stupidity in library headers. It's also often useful to replace broken macros with working versions.
gritzko 4mo ago
What is the feasible way to test code against the matrix of compilers/oses?
- aDyslecticCrow 4mo ago
  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.
  - gritzko 4mo ago
    I think I did not get to that level yet where I trust Claude to create its own VMs. But one day I will.
- btrettel 4mo ago
  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).
- pocksuppet 4mo ago
  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?
WalterBright 4mo ago
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/importc.h https://github.com/dlang/dmd/blob/master/druntime/src/import... https://github.com/dlang/dmd/blob/master/druntime/src/__importc_builtins.di https://github.com/dlang/dmd/blob/master/druntime/src/__impo...
fuhsnn 4mo ago
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_thirdparty.bash https://github.com/fuhsnn/slimcc/blob/main/scripts/linux_thi... [2] https://github.com/fuhsnn/slimcc/blob/main/slimcc_headers/platform_fix/ 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)
- upvotrsuper 4mo ago
  Although I don't use slimcc, I follow its development because I learn so much about C - even though I've been using C and C++ for over 30 years. https://github.com/fuhsnn/slimcc/blob/main/scripts/linux_thirdparty.bash https://github.com/fuhsnn/slimcc/blob/main/scripts/linux_thi... is an incredible piece of work. I can't imagine how many hours it took to assemble this collection. If slimcc can pass that project list torture test, then surely it's bulletproof.
meghprkh 4mo ago
Why would they not do something like? + #if !(defined __GLIBC_COMPILER_SUPPORTS_ATTRIBUTES__) - #if !(defined __GNUC__ || defined __clang__ || defined __TINYC__) # define __attribute__(xyz) /* Ignore */ #endif (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/ 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 https://en.cppreference.com/cpp/utility/feature_test )
- ventana 4mo ago
  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.
  - fc417fc802 4mo ago
    The ideal isn't feature flags (ie FOO_SUPPORTED) but rather feature tests (ie COMPILES( foo( int ) ) ). Yet another reason why languages with proper metaprogramming capabilities are better.
    - account42 4mo ago
      The problem is that COMPILES( foo( int ) ) is not the same as DOES_WHAT_I_WANT_IT_TO( foo( int ) ).
      - 4mo ago
rurban 4mo ago
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.
- lelanthran 4mo ago
  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.)
- einpoklum 4mo ago
  If the codebase is small, and the dependencies are minimal, you might look into trying to integrate your rcc in "bootstrapping" flows, which currently often rely on tcc as a stepping stone towards gcc. And perhaps even being able to skip gcc 4.7 in favor of your compiler, if it's capable of, say, compiling a modern gcc to work even suboptimally.
  - rurban 4mo ago
    tcc is pretty good for this. What I want to explore is cheap and fast optimizations, without SSA and data flow tracking. I have huge sources files compiled to 25MB .o files, which should need to be compiled in less than 5m. So far only tcc can do that. But I have now consteval and deadcode elimination for free. Which tcc cannot do.
deleted 4mo ago
[deleted]
einpoklum 4mo ago
> Anyone who's written C knows that full ISO C standard-adhering code is an impractical rarity. I've written quite a bit of C code and do not know that to be a rarity. Especially when it comes to libraries rather than applications, and FOSS as opposed to proprietary code. > Most real world C code out there relies on non-standard behaviors and language extensions to varying extents Maybe it depends on which domain you're working in. At companies whose target platform is not a PC, relying on idiosycratic behavior, or extensions, is difficult: The compiler for the target device may simply not support the bells and whistles of GCC or whatever, so you stick to C99, (or even C89, ugh) to be on the safe side. And even then there will be things which are standard, but... well, I would be wary of relying on them being supported robustly enough, e.g. variable-length arrays. And of course, once your code does not target just one single machine then you're forced to have to worry about portability and standard compliance etc.
- kouosi 4mo ago
  > And of course, once your code does not target just one single machine then you're forced to have to worry about portability and standard compliance etc. Well linux exclusively usages gcc to compile.
  - fanf2 4mo ago
    https://www.kernel.org/doc/html/latest/kbuild/llvm.html https://www.kernel.org/doc/html/latest/kbuild/llvm.html
    - Maxatar 4mo ago
      That's a good point, the more precise statement is that Linux exclusively uses gnu11 to compile. Clang happens to implement gnu11, I think it's the only non-GCC compiler to do so.
    - pjmlp 4mo ago
      Which was largely sponsored by Google, as they removed GCC from Android, and needed to have clang compile the Linux kernel. For a long time only Android Linux kernel downstream supported it.
cocodill 4mo ago
[flagged]
kscarlet 4mo ago
I think the Common Lisp ecosystem sets a good example of how a dozen of implementations move ahead together. Implementations experiment with extensions, the really useful ones get implemented multiple times, and some portability library emerges as de-facto standard if it's good enough. You can watch the result in https://portability.cl/ https://portability.cl/, the language is evolving like never before even if the standard committee has dissolved nearly 40 years ago!
- eska 4mo ago
  Isn’t this only possible in lisp due to the strong foundations of meta programming allowing the implementation of language features as user libraries?
  - cestith 4mo ago
    I don’t know that it’s impossible without that. It’s certainly easier with it.
  - kscarlet 4mo ago
    Not directly. Every "extensions" listed above cannot be implemented as user libraries, that's why these back and forth process between implementation extensions and portability user libraries need to happen to reach a de-facto standard. Otherwise the user libraries become de-facto standard themselves, like ASDF the build system, Trivia the pattern matcher... But I think the power dynamics is crucial. In the Lisp ecosystem the users have great power, (and there are dozens of implementations,) so it's not like one or two implementation decides what everyone is gonna use and everyone just lives with it.
ndesaulniers 4mo ago
> it took significant effort to e.g. get clang to compile the Linux kernel (needing patches in both projects). Tell me about it. :-)
arikrahman 4mo ago
I'm in the middle of targeting Dart C FFI for Jank lang. The Zig toolchain has been helpful for simplifying the complexity, similar to how Bun simplified JS devwork. This article is relevant as some libraries have to be considered in building the jank package with glib libraries on a Nix flake.
fithisux 4mo ago
We need more C11 and C23 compilers. We need more betterC compilers, we have one (five if you count C3, ZenC, SafeC and Zig but they are not betterC) And we need more assemblers.
user2342 4mo ago
> For example, clang defines __GNUC__=4 (and __GNUC_MINOR__=2, __GNUC_PATCHLEVEL__=1) to claim compatibility with GCC 4.2.1. Is this because Apple at some point stopped updating GCC because of the GPL license change? I think GCC 4.2.x was the last GCC licensed under GPLv2. Could be for compatibility reasons for Mac software.
ryanshrott 4mo ago
[dead]

175 points by xngbuilds 4mo ago

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).

formerly_proven 4mo ago
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.
- zephen 4mo ago
  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.
  - account42 4mo ago
    > which, as the article notes, glibc is also completely hostile to This is neither true nor claimed by the article.
    - zephen 4mo ago
      The article specifically states "If you aren't gcc, clang, or tcc, tough luck." It doesn't work. For no good reason. Because there are a few anointed compilers. That it wasn't on purpose doesn't make it not hostile.
- deleted 4mo ago
  [deleted]
- jdw64 4mo ago
  in Asia, and over here, Windows is the de facto standard while Linux is actually a poor option. Almost all of the infrastructure is written for Windows, so the second you switch to Linux, you're fighting an uphill battle just to do basic tasks. Seeing this makes you realize that our worldview is entirely shaped by the ecosystem we live in
- whizzter 4mo ago
  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.
  - rootnod3 4mo ago
    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.
  - matheusmoreira 4mo ago
    Superiority complex? How many times have we been told that we're entitled freeloaders for expecting Linux compatibility work from others? Insulted by people who use dominant platforms that get all the commercial support while we get literally nothing? Reduced to reverse engineering stuff with no documentation and zero help? Pretty wild to watch this unfold. Now that Linux is finally coming out ahead, as it should, because people are finally writing software for it... Suddenly we're the bullies.
BadBadJellyBean 4mo ago
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.
- whizzter 4mo ago
  Yeah, I think I did miss mentioning that my comment was more weighted on simpler cli tools or library projects (file format readers,etc). I don't expect anyone writing GUI tools or more high-perf servers to spend their time porting to other platforms (trying to compile GTK on Windows wasn't for the faint of heart).
kps 4mo ago
>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/thMt3RfByAgJ?pli=1 https://groups.google.com/g/comp.lang.c/c/CYgWkWdWCcQ/m/thMt... https://www.lysator.liu.se/c/ten-commandments.html https://www.lysator.liu.se/c/ten-commandments.html
dooglius 4mo ago
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.
- rurban 4mo ago
  That ship sailed already. You simply have to mimic gcc. Which is at least better than with MSVC, where they did everything differently, and only half of it.
  - account42 4mo ago
    Well in practice you have to mimic GCC except for Windows where you have to mimic MSVC.
    - rurban 4mo ago
      Not really. MSVC is too broken. I just mimic x86_64-w64-mingw32-gcc, which exists everywhere.
rwmj 4mo ago
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).
- jstimpfle 4mo ago
  What do you even miss, honestly works fine for me? In terms of platform APIs, I prefer the Windows ones on Windows anyway
  - drwu 4mo ago
    Complex numbers, for example. Also, C preprocessor expands macros differently on MSVC.
    - david2ndaccount 4mo ago
      Use the new standards-conformant preprocessor with `/Zc:preprocessor` https://learn.microsoft.com/en-us/cpp/build/reference/zc-preprocessor?view=msvc-170 https://learn.microsoft.com/en-us/cpp/build/reference/zc-pre...
    - jstimpfle 4mo ago
      Wasn't aware of preprocessor conformity issues, good to know!
- bigbadfeline 4mo ago
  > 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). I'm not sure why you're surprised, the parent of you comment clearly stated "on FreeBSD you often run into systemd dependencies or other non-posix behaviors" which means, software written for Linux often uses "Linux-only features" such as systemd and other non-posix dependencies that are foreign to the BSDs and traditional UNIX. Thus, it shouldn't be surprising that Linux software is hard to port to the BSDs. Linux used to be a pretty good UNIX, I'm not sure what it is now.
einpoklum 4mo ago
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".
- jeltz 4mo ago
  No, systemd is not the bane of Linux. What existed before it was much worse. Upstart was a totally broken mess and almost all sysv init scripts contained several bugs. I don't like systemd but it is a lesser evil.
  - einpoklum 4mo ago
    systemd is not an init system; it _contains_ an init system. It is a huge swatch of the whole userspace of a Linux system up to shell or GUI sessions - and having an init system was just an excuse; and in fact, the systemd point brought up in the linked article is unrelated to init systems. There are quite a few init systems: The venerable sysvinit, runit, s6, openrc and others. You don't like upstart? Ok, choose another one, there are many. Here is a comparison table by the Gentoo folks: https://wiki.gentoo.org/wiki/Comparison_of_init_systems https://wiki.gentoo.org/wiki/Comparison_of_init_systems As for the claim of "almost all sysvinit scripts contained several bugs" - that's both hyperbole and false. Plus, you seem to be implying that systemd has not been troubled by bugs, which of course it has (and that does not disqualify it; the fundamental design and organizational nature as a project are the disqualifiers).
    - cestith 4mo ago
      The systemd init system is quite the Trojan horse, though. I prefer it greatly to SystemV init. Most of the rest of systemd varies from unremarkable to problematic in my opinion. One bright spot is systemd-networkd allows one to change quite a few things about interfaces in the way server automation platforms expect to work without doing a network restart. The workaround otherwise on, say, CentOS was always to write the new config file used by future restarts, also run CLI commands to update things in memory, and be sure to tell the service not to trigger a restart on the config file(s) changing. Otherwise if you’re doing something like streaming UDP video your own automation can become a reliability issue.
matheusmoreira 4mo ago
> 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). Windows users singling out Linux users for not catering to their platform. How the times change... > you often run into systemd dependencies or other non-posix behaviors Not a problem. POSIX is irrelevant, systemd is great and we should all be using Linux to its fullest extent. Linux has great features and there is absolutely no reason not to use them all. Nobody complains about the fact BSDs have cool things like kqueue and unveil.
- neonz80 4mo ago
  > Windows users singling out Linux users for not catering to their platform. How the times change... In my experience this was a problem over 25 years ago when I developed for Solaris and other non-Linux operating systems.
  - benj111 4mo ago
    I think I may(?) have got into Linux 20+ years ago when I was trying to learn c and even the basic Hello World wouldn't work for me. So I suppose it does have a marketing benefit in that I now use Linux.
- whizzter 4mo ago
  > Windows users singling out Linux users for not catering to their platform. How the times change... This goes back to the days I was browsing freshmeat and saw some interesting command line tool or otherwise non-UI tool from some hopeful developer for something useful. Node had significant traction but didn't really blow up until it became really cross-platform. And perhaps is less of an issue these days since so many people use Mac's as their primary, so less Linux-isms survive once in context with osX. > Not a problem. POSIX is irrelevant, systemd is great and we should all be using Linux to its fullest extent. Linux has great features and there is absolutely no reason not to use them all. Nobody complains about the fact BSDs have cool things like kqueue and unveil. From following it over the year it was not entirely welcomed even in the linux community (and some of the security issues made one shudder). Mostly it's the monolithic nature that's makes it a questionable, is it Gnu/Linux these days or Systemd/Linux ? kqueue is just an api, just like epoll, io_uring or even iocp on windows. And yes, it's a special case for high-perf servers where posix becomes less relevant (and while I can appreciate some lower-perf fallback to be able to develop/port to another platform like a console I do see that some programs are inherently platform bound). I think one thing lost in my original comment was that I was often encountering things like this with "simple" CLI tools or lower level format libraries, and honestly projects like that also had a tendency to break over time without updates as they often relied on specific versions of libraries the maintainers had installed via Linux package managers, in the same fashion as npm has caused churn in the JS community. (npm at least has version pinning so old cli tools can often be run as long as node hasn't deprecated api's).
dgrunwald 4mo ago
In our compiler (in a code analysis tool), we have #pragma immutable_macro __attribute__ After this pragma, any attempt to #define/#undef the macro "__attribute__" will be silently ignored. This lets us (or our customers) bypass such stupidity in library headers. It's also often useful to replace broken macros with working versions.

gritzko 4mo ago

What is the feasible way to test code against the matrix of compilers/oses?

aDyslecticCrow 4mo ago
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.
- gritzko 4mo ago
  I think I did not get to that level yet where I trust Claude to create its own VMs. But one day I will.
btrettel 4mo ago
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).
pocksuppet 4mo ago
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?

WalterBright 4mo ago

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/importc.h https://github.com/dlang/dmd/blob/master/druntime/src/import... https://github.com/dlang/dmd/blob/master/druntime/src/__importc_builtins.di https://github.com/dlang/dmd/blob/master/druntime/src/__impo...

fuhsnn 4mo ago

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_thirdparty.bash https://github.com/fuhsnn/slimcc/blob/main/scripts/linux_thi... [2] https://github.com/fuhsnn/slimcc/blob/main/slimcc_headers/platform_fix/ 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)

upvotrsuper 4mo ago
Although I don't use slimcc, I follow its development because I learn so much about C - even though I've been using C and C++ for over 30 years. https://github.com/fuhsnn/slimcc/blob/main/scripts/linux_thirdparty.bash https://github.com/fuhsnn/slimcc/blob/main/scripts/linux_thi... is an incredible piece of work. I can't imagine how many hours it took to assemble this collection. If slimcc can pass that project list torture test, then surely it's bulletproof.

meghprkh 4mo ago

Why would they not do something like? + #if !(defined __GLIBC_COMPILER_SUPPORTS_ATTRIBUTES__) - #if !(defined __GNUC__ || defined __clang__ || defined __TINYC__) # define __attribute__(xyz) /* Ignore */ #endif (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/ 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 https://en.cppreference.com/cpp/utility/feature_test )

ventana 4mo ago
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.
- fc417fc802 4mo ago
  The ideal isn't feature flags (ie FOO_SUPPORTED) but rather feature tests (ie COMPILES( foo( int ) ) ). Yet another reason why languages with proper metaprogramming capabilities are better.
  - account42 4mo ago
    The problem is that COMPILES( foo( int ) ) is not the same as DOES_WHAT_I_WANT_IT_TO( foo( int ) ).
    - 4mo ago

rurban 4mo ago

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.

lelanthran 4mo ago
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.)
einpoklum 4mo ago
If the codebase is small, and the dependencies are minimal, you might look into trying to integrate your rcc in "bootstrapping" flows, which currently often rely on tcc as a stepping stone towards gcc. And perhaps even being able to skip gcc 4.7 in favor of your compiler, if it's capable of, say, compiling a modern gcc to work even suboptimally.
- rurban 4mo ago
  tcc is pretty good for this. What I want to explore is cheap and fast optimizations, without SSA and data flow tracking. I have huge sources files compiled to 25MB .o files, which should need to be compiled in less than 5m. So far only tcc can do that. But I have now consteval and deadcode elimination for free. Which tcc cannot do.

deleted 4mo ago

[deleted]

einpoklum 4mo ago

> Anyone who's written C knows that full ISO C standard-adhering code is an impractical rarity. I've written quite a bit of C code and do not know that to be a rarity. Especially when it comes to libraries rather than applications, and FOSS as opposed to proprietary code. > Most real world C code out there relies on non-standard behaviors and language extensions to varying extents Maybe it depends on which domain you're working in. At companies whose target platform is not a PC, relying on idiosycratic behavior, or extensions, is difficult: The compiler for the target device may simply not support the bells and whistles of GCC or whatever, so you stick to C99, (or even C89, ugh) to be on the safe side. And even then there will be things which are standard, but... well, I would be wary of relying on them being supported robustly enough, e.g. variable-length arrays. And of course, once your code does not target just one single machine then you're forced to have to worry about portability and standard compliance etc.

kouosi 4mo ago
> And of course, once your code does not target just one single machine then you're forced to have to worry about portability and standard compliance etc. Well linux exclusively usages gcc to compile.
- fanf2 4mo ago
  https://www.kernel.org/doc/html/latest/kbuild/llvm.html https://www.kernel.org/doc/html/latest/kbuild/llvm.html
  - Maxatar 4mo ago
    That's a good point, the more precise statement is that Linux exclusively uses gnu11 to compile. Clang happens to implement gnu11, I think it's the only non-GCC compiler to do so.
  - pjmlp 4mo ago
    Which was largely sponsored by Google, as they removed GCC from Android, and needed to have clang compile the Linux kernel. For a long time only Android Linux kernel downstream supported it.

cocodill 4mo ago

[flagged]

kscarlet 4mo ago

I think the Common Lisp ecosystem sets a good example of how a dozen of implementations move ahead together. Implementations experiment with extensions, the really useful ones get implemented multiple times, and some portability library emerges as de-facto standard if it's good enough. You can watch the result in https://portability.cl/ https://portability.cl/, the language is evolving like never before even if the standard committee has dissolved nearly 40 years ago!

eska 4mo ago
Isn’t this only possible in lisp due to the strong foundations of meta programming allowing the implementation of language features as user libraries?
- cestith 4mo ago
  I don’t know that it’s impossible without that. It’s certainly easier with it.
- kscarlet 4mo ago
  Not directly. Every "extensions" listed above cannot be implemented as user libraries, that's why these back and forth process between implementation extensions and portability user libraries need to happen to reach a de-facto standard. Otherwise the user libraries become de-facto standard themselves, like ASDF the build system, Trivia the pattern matcher... But I think the power dynamics is crucial. In the Lisp ecosystem the users have great power, (and there are dozens of implementations,) so it's not like one or two implementation decides what everyone is gonna use and everyone just lives with it.

ndesaulniers 4mo ago

> it took significant effort to e.g. get clang to compile the Linux kernel (needing patches in both projects). Tell me about it. :-)

arikrahman 4mo ago

I'm in the middle of targeting Dart C FFI for Jank lang. The Zig toolchain has been helpful for simplifying the complexity, similar to how Bun simplified JS devwork. This article is relevant as some libraries have to be considered in building the jank package with glib libraries on a Nix flake.

fithisux 4mo ago

We need more C11 and C23 compilers. We need more betterC compilers, we have one (five if you count C3, ZenC, SafeC and Zig but they are not betterC) And we need more assemblers.

user2342 4mo ago

> For example, clang defines __GNUC__=4 (and __GNUC_MINOR__=2, __GNUC_PATCHLEVEL__=1) to claim compatibility with GCC 4.2.1. Is this because Apple at some point stopped updating GCC because of the GPL license change? I think GCC 4.2.x was the last GCC licensed under GPLv2. Could be for compatibility reasons for Mac software.

ryanshrott 4mo ago

[dead]