Hacker News new | past | comments | ask | show | jobs | submit

C extensions, portability, and alternative compilers

https://lemon.rip/w/6-c-extensions-compilers/
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).

loading story #48268512
loading story #48268475
loading story #48267481
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...

loading story #48268732
loading story #48268905
loading story #48268899
What is the feasible way to test code against the matrix of compilers/oses?