What is the feasible way to test code against the matrix of compilers/oses?
For open source? Test on your platform, release the code, and then wait for the bug reports/patches. Not even kidding.
C extensions, portability, and alternative compilers
71–80 of 97 posts
Re: C extensions, portability, and alternative compilers
#72One 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…
In our compiler (in a code analysis tool), we have
#pragma immutable_macro __attribute__
Re: C extensions, portability, and alternative compilers
#73Earlier quoted context omitted.
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…
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 , b…
This isn't a new thing, like I mentioned in another comment it goes back to freshmeat.net days ("oh, cool a tool to manipulate fileformat-x", "oh ok too full of gcc-isms, linux-only headers to run on either windows or even bsd").
I worked in gamedev, consoles, etc. Linux support was often discussed but the whole mess of different libraries on various distros vs static library linkage legality, evolving audio api's,etc was real blockers (Valve just defaulting on Wine and Win32 binaries for steamdecks could be discussed at length).
Honestly, could even be posited that the rise of the Web as a delivery platform, Java and Node,etc is in large part DUE to the fragmented story of much of C/C++ code platform-tiedness, Linux just happened to move ahead due to it's momentum as the "free" option (quotation marks due to Android).
Re: C extensions, portability, and alternative compilers
#74Earlier quoted context omitted.
What do you even miss, honestly works fine for me? In terms of platform APIs, I prefer the Windows ones on Windows anyway
Complex numbers, for example. Also, C preprocessor expands macros differently on MSVC.
Wasn't aware of preprocessor conformity issues, good to know!
Re: C extensions, portability, and alternative compilers
#75Earlier quoted context omitted.
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.
The problem is that COMPILES( foo( int ) ) is not the same as DOES_WHAT_I_WANT_IT_TO( foo( int ) ).
Naturally you can also implement DOES_WHAT_I_WANT_IT_TO( foo( x ) ) as a follow on. For example I have some code that relies on specific IEEE floating point properties; rather than hope for the best I explicitly test the behavior at program initialization. I also have lots of compile time tests of the form constexpr does_what_I_want() { ... } static_assert( does_what_I_want() ).
Re: C extensions, portability, and alternative compilers
#76One 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…
Generally speaking, if someone is not actively using/hacking software on a particular platform, support for that platform can fall in a hole. It's often not hard to add, however, if the code base is well written and keeps portability in mind. I fixed an issue with NetBSD support in GrafX2 (pixel art editor) some years back in like fifteen minutes.
Re: C extensions, portability, and alternative compilers
#77Earlier quoted context omitted.
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.
> which, as the article notes, glibc is also completely hostile to This is neither true nor claimed by the article.
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.
Re: C extensions, portability, and alternative compilers
#78Earlier quoted context omitted.
> 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…
Linux used to be a pretty good UNIX, I'm not sure what it is now. Linux has become Linux, it's own thing that as often as not says "yeah, that old Unix stuff is fine for you boomers and other fossils...we're going to be over here doing our own thing". Which is probably fine, I guess, because all the old Unix versions did the same thing to some extent and the computing world had changed over a dozen times since Unix s…
Also, people confuse "good" with "ought to live forever". It's time to leave BSD and LISP in the history books.
Re: C extensions, portability, and alternative compilers
#79Earlier quoted context omitted.
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.
Well in practice you have to mimic GCC except for Windows where you have to mimic MSVC.
Not really. MSVC is too broken. I just mimic x86_64-w64-mingw32-gcc, which exists everywhere.
Re: C extensions, portability, and alternative compilers
#80Earlier quoted context omitted.
> 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 grea…
> 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.
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.