Already we've got a good representative example of why C is so frustrating. The first step in the freeWAIS build process is to compile the file "config.c", run "./config", and write the output to "config.h" -- analogous to Autoconf. In only 117 lines, it manages to run into the following UB/unportability/misc problems:
Fails to include stdlib despite referencing exit(), which creates an implicit definition of exit as "extern int exit()" that contradicts the actual prototype "extern void exit(int)".
Defines main with the signature "int main()". This is not one of the two allowed ways to define main, as it is not equivalent to int main(void), and empty-paren declarators are an obsolescent feature anyways. (This is correct in C23, however.)
Declares a bunch of unused variables. C89's "declarations up front" rule makes it difficult to tell which variables are actually used at a glance without asking the compiler. In this case, 7/14 are unused. (One of which is written to but never read from -- the others are completely unused).
Tests that sizeof(char) is equal to 1. It is guaranteed to be 1 by the standard. (Obviously at the time it mattered that you tried to cater to noncompliant compilers too, but this configure program isn't sophisticated enough to actually handle such a compiler.)
Calls printf() with a potentially-too-small %d conversion specifier for a size_t argument.
Calls exit(1) to mean a failure. C89 makes exit's behavior with any argument other than EXIT_SUCCESS, 0, or EXIT_FAILURE implementation-defined.
Forgets to call exit() in the case where they couldn't define four_byte, which will result in accessing an uninitialized variable on line 92.
Tests alignment for a few types by casting pointers to int and subtracting them. This is maybe defined, if your pointers can fit in an int. If they can't that's UB. If they can, the result is still entirely implementation-defined. Implementations are allowed to "stuff" extra information in the bottom of pointers with > 1 stride, for example. Raw pointer subtraction is also implementation-defined, and in this case subtracting two pointers that don't point to the same array object is undefined.
Tests endianness by casting a unsigned long to (essentially) a char array. char is not guaranteed to be 8-bit -- this endianness check fails to take advantage of our earlier work to get absolutely-sized types -- the values of these de-references are unspecified (or possibly UB? The C89 standard is fuzzy and doesn't make the explicit aliasing carve-out for char* that C99 does), and by failing to check the ordering of the middle bytes we potentially misunderstand the reality of our operating environment.
And that's not even mentioning the style issues!
What do we even do with this? Rewrite it? How? This program can't even be written in C89. There is no combination of operations with the necessary semantics. It's like trying to build a real perpetual motion machine by just obeying the laws of thermodynamics harder. How the fuck am I supposed to get struct member alignment without alignof or well-defined pointer comparison? You want me to use offsetof? Are you kidding me?
Is this really a "high-level assembler" if I cant do basic address calculations like alignof? I don't care if that makes my program unportable to some other systems which can't do address calculations, the point of my program is to do address calculations! I want that to be a compilation error!
But oh nooooooooooo, we can't fracture the ecosystem by adding standardized optional features. Don't you remember C99? Poor MSVC will feel so left out! The solution is to make everything useful a nonstandard optional feature. "You want to write software that isn't portable to the three worst Harvard architectures of 1954, but will run on everything else? Oh so you want to do something we didn't define? Oh so you HATE portability actually? Oh so you want to write low-level code? Oh so you're evil? Oh so you're actually a terrible person? Well then start passing everything behind tagged void pointers and get to memorizing the builtins of the top twenty most popular compilers, stupid!"
As of C23, we can write an equivalent program in about 37 lines; and it's entirely redundant because we're just defining macros that wrap new standard macros (or operators).
Which begs a lot of questions. Why were we writing C again? Oh right, to fix up a decaying C89 codebase. Is it really a good idea to do that by maintaining two different standards versions in the same source tree at the same time? They aren't compatible forwards or backwards, and we can't declare the language version within a file, either. And what happens when we need to write a program that C23 can't express? Use only compilers with up-to-date experimental C2y support? Weren't we trying to be more portable? What even is "portable"? Or an assembler? Or a Dennis Ritchie? Is this actually more of a "real programmer" language than just string templating yaml helm charts all day, if we have to inject all the real meaning into our program at configure-time? Does God really love us?
vaporwave
stormborns
titsay
germansingergirl
izzy806
origamiaround
kaledo-art
