Hacker News Reader

Comment by dietr1ch | Hacker News Reader

> relying on compiler vendor extensions kind of defeats the purpose of that.

Let's be honest, how many compilers are available, and how many of those would you actually use?

The answer isn't more than 4 and the 2 compilers you are most likely to use among those already support this and probably won't stop supporting without a good alternative.

I like standardisation, but you have to be realistic when it helps you without a large real cost other than fighting your ideals for getting this into the standard first.

View on HN

For me, the point of writing something in C is portability. There were C compilers 30 years ago, there are C compilers now, and there will almost certainly be C compilers 30 years from now. If I want to write a good, portable library that's going to be useful for a long time, I'll do it in C. This is, at least, the standard in many gamedev circles (see: libsdl, libfreetype, the stb_* libraries). Under that expectation, I write to a standard, not a compiler.

The bad news is that C23 broke a lot of existing code[1]. We had to do a lot of work in Fedora to fix the resulting mess. [1] https://gcc.gnu.org/gcc-15/porting_to.html#c23

For the cases in linked doc, does adding -std=gnu17 to packages not suffice?

I would consider the union initializer change (require adding -fzero-init-padding-bits=unions for old behavior) much more hidden and dangerous, which is not directly related to ISO C23 standard.

It's true that it does, yes. However that would still require changes to the build system. In any case for the vast majority of the packages we decided to fix (if you think this is a fix!) the code.

>if you think this is a fix

I would count it as doing maintenance work for the upstream, kudos for doing this!

> Note that the bool type is not the same as int at ABI level,

Huh. Wonder what the benefits of that are. Bools being ints never struck me as a serious problem. I wonder if this catches people who accidentally assign rather than compare tho....

If I touch C it has to have control over allocations, memory layout, and wrapping low level code into functions I can call from other languages.

I'd target the latest C standard and won't even care to know how many old, niche compilers I'm leaving out. These are vastly different uses for C and obviously your gaols drastically change your standard or compiler targeted.

For accessing any post-1970s operating system feature (e.g. async IO or virtual memory) you already cannot use standard C anymore (and POSIX is not the C stdlib).

The libraries you listed are all full of platform-specific code, and also have plenty of compiler-specific code behind ifdefs (for instance the stb headers have MSVC specific declspec declarations in them).

E.g. there is hardly any real-world C code out there that is 'pure standard C', if the code compiles on different compilers and for different target platforms then that's because the code specifically supports those compilers and target platforms.

My argument is that using these non-standard extensions to do important things like memory management in a C library is malpractice—it effectively locks down the library to specific C compilers. I'm sure that's fine if you're writing to clang specifically, but at that point, you can just write C++. libfreetype & stb_* are used and continue to be used because they can be relied on to be portable, and using compiler-specific extensions (without ifdefs) defeats that. If I relied on a clang-specific `defer`, I'm preventing my library from possibly being compiled via a future C compiler, let alone the compilers that exist now. To me, that's the point of writing C instead of C++ for a library (unless you're just a fan of the simplicity, which is more of an ideological, opinion-based reason).

There are quite a lot of embedded code that relies on obscure C compilers created and maintained by the CPU manufacturer.

But then again you are probably not doing a whole lot of heap management in embedded code.

That sounds like the kind of code that you want to be done with and never touch again. You can only dream of it not being buggy or catching up with the newest standard.

No it is more like the 10000 lines of code running in your washing machine, you will probably be updating it in the next year revision of the product.

It is quite common for this code to have all variables be global and just not have any heap allocations at all. Sometimes you don't even have variables in the stack either (besides the globals).

I much prefer the purely-mechanical washing machines for this reason.. Way less to go wrong..

It is not that bad, the code is easier than your average web server and it is usually only one CPU for consumer devices. It gets bad if:

1) You add embedded linux

2) You have multiple CPUs that need to communicate with each other.

3) Both of the above (then the complexity skyrockets)

(this happens in modern cars)

So basically if it has a full LCD display (instead of 7-segment with a few extra toggle lights) I don't buy it.

It is actually quite refreshing code to read and write, yes the quality is often bad, but it often feels like school projects where they are small enough you can hold the complete system in your head. And it usually doesn't integrate with anything else besides the eletronics in the board

static allocation is the recommended mechanism in embedded code for reliability reasons, you have thought about you worst-case allocation and accounted for it... right? Also fragmentation and dynamic behaviour are bad things when your code has to run "forever".

If this is the argument then the actual standardisation is useless. I primarily use windows so I’m affected by one of the major compilers that doesn’t support this feature. This is no different to saying “chrome supports feature X, and realistically has y% market share so don’t let the fact that other browsers exist get in the way”.

Call it a posix extension, fair enough. But if your reason for writing C is that it’s portable, don’t go relying on non portable vendor specific extensions.

It's not, and even if there's something in the standard, your compiler of choice might not support it yet.

It's the same thing with the web and browser vendors, there's a constant mismatch, browsers propose and implement things and they may get standardized, and the standard dictates new requirements which might get implemented by all vendors.

The point of standardisation is defining behaviour for the things that are implemented as exploratory improvements and should be implemented on the more conservative compilers.

It's your choice whether to target the standard or a few selected compilers, there's a cost for both options between being late to improvements vs the possibility of needing to revisit your code around each of the "extensions" you decided to depend on.

If in certain projects portability is somehow of upmost importance, then any discussion around looking through the standard's black box to reach out for new stuff is kind of useless.

Reply on news.ycombinator.com