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

▲ rwmj 2 hours ago | parent | next [-]

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

▲ matheusmoreira an hour ago | parent | prev | next [-]

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

▲ BadBadJellyBean 4 hours ago | parent | prev | next [-]

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.

▲ kps 3 hours ago | parent | prev | next [-]

>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

▲ dooglius 3 hours ago | parent | prev | next [-]

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.

▲ formerly_proven 5 hours ago | parent | prev | next [-]

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.

▲

whizzter 3 hours ago | parent | next [-]

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.

▲

matheusmoreira 44 minutes ago | parent | next [-]

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.

▲

justin66 15 minutes ago | parent [-]

> Now that Linux is finally coming out ahead

Where have you been for the last quarter century?

	▲	matheusmoreira 4 minutes ago \| parent [-]
		Using Linux on my machines despite all the difficulties involved.

▲

rootnod3 2 hours ago | parent | prev [-]

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.

▲

zephen 4 hours ago | parent | prev | next [-]

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.

▲

4 hours ago | parent | prev | next [-]

[deleted]

▲

jdw64 4 hours ago | parent | prev [-]

[dead]

▲ einpoklum 2 hours ago | parent | prev [-]

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