GCC still not implementing the standard pragmas reminds me of the old GCC pragma easter egg. This is in cccp.c from gcc 0.9:
/*
* the behavior of the #pragma directive is implementation defined.
* this implementation defines it as follows.
*/
do_pragma ()
{
close (0);
if (open ("/dev/tty", O_RDONLY) != 0)
goto nope;
close (1);
if (open ("/dev/tty", O_WRONLY) != 1)
goto nope;
execl ("/usr/games/hack", "#pragma", 0);
execl ("/usr/games/rogue", "#pragma", 0);
execl ("/usr/new/emacs", "-f", "hanoi", "9", "-kill", 0);
execl ("/usr/local/emacs", "-f", "hanoi", "9", "-kill", 0);
nope:
fatal ("You are in a maze of twisty compiler features, all different");
}
It's gone by gcc 1.21:
#if 0
/* This was a fun hack, but #pragma seems to start to be useful.
By failing to recognize it, we pass it through unchanged to cc1. */
...
#endif
Well, considering that gcc doesn't support the FENV_ACCESS pragma, and as such all fesetround calls are always UB, it is valid for it to act as if the rounding mode never changes from the default :)
As someone who loves and enjoys writing Plan 9 c, all I can say is "standard c", whatever that means these days, is a mess. Too many things to name ranging from the only two oss compilers being bloated monsters, post c99 additions being pointless, in-line asm ruining portability*, and POSIX can die in a fire (along with typewriter terminals.)
I have a friend who is currently on the C committee and is likely going to leave because of all the bad ideas which have both been implemented and going to be implemented.
* No, spamming a million ugly #ifdefs all over the source files is gross and hard to read. Split up the code dammit.
Plan 9 inheritance is really nice. You can still use it with `gcc -fplan9-extensions`. It builds some nice polymorphic workflow an array of tagged enum void pointers
> You can do it all with library functions that just take regular int* (and so on).
It's not just about atomics, but you might still find Hans Boehm's 2005 paper "Threads Cannot Be Implemented As a Library" [0] interesting. It describes (among other things) correctness and performance issues that can arise if the compiler and/or language don't know about thread/atomic semantics.
Compilers have, for several decades now, stopped viewing optimization in terms of optimizing the instructions of a function and instead viewed it as preserving the semantics under some machine model. Consequently, it's rather important to actually nail down some of the object model semantics to be able to do things like understand which loads and stores actually need to be preserved, and you can't really do that with just library functions.
And, FWIW, in a lot of high-performance code, the overhead of a function call may be too high for an atomic operation.
A library function written in what? Atomics also come along with memory ordering which isn’t otherwise expressible in the language, as in, there was no standard way to do a “load acquire” before, for example.
There's a lot of post-C99 that has somewhat questionable value (_Generic is very much a we-have-templates-at-home kind of feature), but there are some post-C99 features that I'm rather happy to have:
* thread_local and _Atomic support from C11
* fopen("foo", "x") from C11
* aligned_alloc from C11
* CMPLX macro from C11
* C++ attribute syntax ([[foo]] flows better to me than __attribute__((foo)) does)
* Some of the new operations like ckd_add or stdc_rotate_left. I do dislike the names, but meh, at least C is starting to gain a competent set of fundamental operations.
Also, C23 (and C2y) is moving ever closer to actually having defined semantics. As in, "just because one branch of your code, for this particular input, read a value out of an array's bounds, your whole program's execution doesn't suddenly rewinds back to the start (with I/O included) and NOPs/loops infinitely".
Also, I'm personally still waiting for a "shift left" operator having cleaner wording in the standard:
If E1 has an unsigned type, the value of the result is E1 × 2**E2, wrapped
around. If E1 has a signed type and nonnegative value, and E1 × 2**E2 is
representable in the result type, then that is the resulting value; otherwise,
the behavior is undefined.
What does "otherwise" means here? It can't mean "if E1 has an unsigned type, or negative value, or E1 × 2**E2 is unrepresentable, then the behavior is undefined" because the part "if E1 has an unsigned type" has already been covered by the previous clause. Does it mean "If E1 has negative value, or E1 × 2**E2 is unrepresentable, then the behavior is undefined"? Because that's a ridiculous ordinance.
GCC still not implementing the standard pragmas reminds me of the old GCC pragma easter egg. This is in cccp.c from gcc 0.9:
It's gone by gcc 1.21:> gcc, however, always defines FLT_ROUNDS to 1
Well, considering that gcc doesn't support the FENV_ACCESS pragma, and as such all fesetround calls are always UB, it is valid for it to act as if the rounding mode never changes from the default :)
As someone who loves and enjoys writing Plan 9 c, all I can say is "standard c", whatever that means these days, is a mess. Too many things to name ranging from the only two oss compilers being bloated monsters, post c99 additions being pointless, in-line asm ruining portability*, and POSIX can die in a fire (along with typewriter terminals.)
I have a friend who is currently on the C committee and is likely going to leave because of all the bad ideas which have both been implemented and going to be implemented.
* No, spamming a million ugly #ifdefs all over the source files is gross and hard to read. Split up the code dammit.
Plan 9 inheritance is really nice. You can still use it with `gcc -fplan9-extensions`. It builds some nice polymorphic workflow an array of tagged enum void pointers
>post c99 additions being pointless
Atomics are necessary nowadays though.
As a part of the language? Are they really? You can do it all with library functions that just take regular int* (and so on).
Not that I'd want it, I like complex type systems, but I see it as philosophically consistent with C.
> You can do it all with library functions that just take regular int* (and so on).
It's not just about atomics, but you might still find Hans Boehm's 2005 paper "Threads Cannot Be Implemented As a Library" [0] interesting. It describes (among other things) correctness and performance issues that can arise if the compiler and/or language don't know about thread/atomic semantics.
[0]: https://web.stanford.edu/class/archive/cs/cs240/cs240.1236/o...
Compilers have, for several decades now, stopped viewing optimization in terms of optimizing the instructions of a function and instead viewed it as preserving the semantics under some machine model. Consequently, it's rather important to actually nail down some of the object model semantics to be able to do things like understand which loads and stores actually need to be preserved, and you can't really do that with just library functions.
And, FWIW, in a lot of high-performance code, the overhead of a function call may be too high for an atomic operation.
A library function written in what? Atomics also come along with memory ordering which isn’t otherwise expressible in the language, as in, there was no standard way to do a “load acquire” before, for example.
There's a lot of post-C99 that has somewhat questionable value (_Generic is very much a we-have-templates-at-home kind of feature), but there are some post-C99 features that I'm rather happy to have:
* thread_local and _Atomic support from C11
* fopen("foo", "x") from C11
* aligned_alloc from C11
* CMPLX macro from C11
* C++ attribute syntax ([[foo]] flows better to me than __attribute__((foo)) does)
* C23 finally gets rid of _Who _The _Hell _Thinks _Users _Like _This-style _Keywords.
* Multi-level break/continue in C2y
* Variable declarations in if conditions.
* Some of the new operations like ckd_add or stdc_rotate_left. I do dislike the names, but meh, at least C is starting to gain a competent set of fundamental operations.
Also, C23 (and C2y) is moving ever closer to actually having defined semantics. As in, "just because one branch of your code, for this particular input, read a value out of an array's bounds, your whole program's execution doesn't suddenly rewinds back to the start (with I/O included) and NOPs/loops infinitely".
Also, I'm personally still waiting for a "shift left" operator having cleaner wording in the standard:
What does "otherwise" means here? It can't mean "if E1 has an unsigned type, or negative value, or E1 × 2**E2 is unrepresentable, then the behavior is undefined" because the part "if E1 has an unsigned type" has already been covered by the previous clause. Does it mean "If E1 has negative value, or E1 × 2**E2 is unrepresentable, then the behavior is undefined"? Because that's a ridiculous ordinance....and I thought Go was standard C!