1 comments

  • whizzter 58 minutes 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 54 minutes 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 11 minutes 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.