|C23 - What We Have To Suffer|
|Written by Harry Fairhead|
|Wednesday, 05 April 2023|
It is a long standing mystery to me that the people who standardize C really don't seem to use it much, or if they do it is in some refined academic way that is purely for amusement. The latest C standard, C23 is due later in the year and it isn't good.
I've been using C for low-level programming throughout most of its standards and for most of the time I have upgraded to the next standard reluctantly. I suppose I'm not as bad as Linus Torvalds and Linux which until recently was stuck on C89 and is now in the process of moving to C11. The best that can be said for C11 is that it didn't break much if you selected the right options. Personally C99 was my choice rather than C11 but there isn't a lot in it.
Now we have the latest attempt to ruin a perfectly good language - C23, shame it wasn't last year as that would have allowed C(atch) 22 jokes. As far as I can tell things started to go wrong when the idea of "undefined behavior" was introduced not as a problem but as a way of allowing compiler writers to resort to optimizations that are simply barbaric in any reasonable programmer's opinion. I still fume daily at the optimization that changes:
An optimization is supposed to never change the action of a program, but clearly C compiler writers have no sense of time.
It is examples like this that indicate that the people in control of C aren't the people who use C. If they were, undefined behavior would be minimized and optimizations wouldn't change the action of a program.
Let me turn to something nice about C23. We now have checked arithmetic.
bool ckd_add(type1 *result, type2 a, type3 b);
The idea is that the functions return false if the arithmetic worked out such that the operation between type2 and type3 produces something that can be represented in type1 without error. If the function returns true then this is not the case and the result is what you would get using unsigned arithmetic and truncating the result. Notice that now two's complement arithmetic is the standard. This is also what you would automatically get on the most common hardware without the functions. The only thing we have extra is the overflow detection. Of course, you can't use these functions for compile-time arithmetic and they don't make expressions easy. I think there are probably better ways of doing the same job.
Now we come to the lunacy of "unreachable". You can mark a code path as unreachable and the compiler will remove it for you. The annotation is intended to allow you to inform the compiler that, to the best of your knowledge, the path cannot be reached. For example:
Why? Why would I ever want to mark a path as unreachable!
Another big problem is the changed behavior of realloc. There are some subtleties here but the big problem is that at the moment:
returns a NULL and frees the memory. This seems reasonable as resizing an allocation to zero should free the memory, i.e. be identical to free(p). The new C23 standard has changed this reasonable and useful behavior to be undefined behavior!!
I was in the middle of writing this complaint when I encountered another and very readable account of the same problem:
After reading it I can't do any better. So simply stop reading my rant at this point and read it, and then come back for a conclusion.
As I suggested at the start, the problem seems to be that the people in charge of the standards seem to think that C is a high- level language that should morph into Java, or worse Haskell or even worse C++. As it happens, C23 increases the split between C and C++ and C23 can no longer be regarded as subset of C++.
The world has lots of high-level abstract languages. C is about bit patterns and representations not abstract types. It is time to take back control and make C a machine-independent assembler and use this definition to banish all undefined behavior into implementation-dependent behavior.
Catch-23: The New C Standard Sets the World on Fire Terence Kelly with Special Guest Borer Yekai Pan
or email your comment to: firstname.lastname@example.org
|Last Updated ( Thursday, 06 April 2023 )|