[deleted]
C extensions, portability, and alternative compilers
21–30 of 97 posts
Re: C extensions, portability, and alternative compilers
#22One 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 __a…
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).
Re: C extensions, portability, and alternative compilers
#23I 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.)
Re: C extensions, portability, and alternative compilers
#24Why 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,…
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.
Re: C extensions, portability, and alternative compilers
#25One 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 __a…
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 ``, 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".
Re: C extensions, portability, and alternative compilers
#26> 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.
Re: C extensions, portability, and alternative compilers
#27[flagged]
Re: C extensions, portability, and alternative compilers
#28I 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.
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.
Re: C extensions, portability, and alternative compilers
#29One 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 __a…
> 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.
Re: C extensions, portability, and alternative compilers
#30> 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…
> 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.