Rendered at 08:16:38 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
omoikane 6 hours ago [-]
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
dzaima 6 hours ago [-]
> 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 :)
uecker 3 hours ago [-]
Well, it is not ok to not support FENV_ACCESS though.
amszmidt 2 hours ago [-]
I skimmed the standard and POSIX, but couldn’t find anything that an implementation is required to support FENV_ACCESS.
“ISO C language standard requires that C compilers support the following three pragmas, and some C++ compiler vendors support them, to varying degrees, in their C++ frontends:
⇒ it seems C compilers must support this (but C++ compilers need not)
MisterTea 1 days ago [-]
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.
WalterBright 4 hours ago [-]
It would be nice for the C Standard to say that `char` is unsigned. The damage done by making its signedness implementation-defined is incalculable.
(D sez `char` is unsigned. No more nonsense!)
C also needs to implement proper arrays. D does it, and that one feature is worth its weight in gold:
It's sooo nice to not have array overflows anymore.
pjmlp 2 hours ago [-]
The problem starts already with being Plan 9, as it was the evolution of UNIX, the authors even played with Alef as C's successor.
In what concerns C itself, as the language authors, they did not care that much about the standard, hence why it is mostly C89 with Rob Pike ideas on how header files should be organised, and other Plan 9 specific idioms.
glouwbug 7 hours ago [-]
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
jcranmer 6 hours ago [-]
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.
Joker_vD 5 hours ago [-]
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, has 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/executes random bytes after main()".
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: (-1) << 1 is UB?!
jcranmer 4 hours ago [-]
> 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.
That's exactly what it means, see the change mentioned in https://www.open-std.org/jtc1/sc22/wg14/www/docs/n723.htm. (Previously, in C89, left shift on signed integers was completely undefined, only unsigned integers had a defined left-shift operation.) My guess is that it has to do with signed-magnitude representation causing left shifts to be absolute garbage with negative numbers. You also have to remember that the standard having undefined behavior doesn't preclude implementations from defining that behavior, and this is especially true with the freewheeling nature of a lot of the original undefined behavior introduced in C89 and C99.
> Also, C23 (and C2y) is moving ever closer to actually having defined semantics.
Eh, having seen how some of the sausage gets made, there's definitely been some cases where the overeager urge to rip out undefined behavior from the standard has worsened the quality.
uecker 3 hours ago [-]
Well, you could start to help? (instead of just being there to make sure special interests are preserved in voting)
I also do not see where the quality suffered. There were some rather minor issues we created and need to cleaned up.
jcranmer 3 hours ago [-]
> (instead of just being there to make sure special interests are preserved in voting)
This kind of attitude tends to make me suspect that you are disinclined to actually listen to my feedback.
uecker 3 hours ago [-]
Prove it. Aaron told me explicitly that he was inviting people because he was not happy that there are too many with a user view point. And then a couple people show up that never contribute papers but consistently vote for some special interest.
jcranmer 2 hours ago [-]
I joined WG14 and WG21 because I was worried that there were not enough people on either committees who had the perspective of someone who works in middle-end optimization rather than the frontend. I haven't written any papers for WG14 because so far all of the feedback I need to give can easily be given merely by discussion on the reflector or during the paper discussions (this is not the case for WG21, and I have consequently written papers for them), and--as a middle-end person--there is actually relatively little feature development for me to specifically propose. Most of the big features I'd want to see included already have active proposals (e.g., _Vec) and there's little reason for me to write a different proposal. Maybe you'll eventually see a paper from me if I take up some of the proposal work for CFP, or if I get around to writing a version of restrict that's based off of the Tree Borrows model. Or maybe if I turn some of my thoughts on multiple return values into a paper, though I don't actually have a proper frontend proposal for that that I like, so it's more likely to remain a reflector message.
uecker 3 hours ago [-]
Just as a recent example. There is a case where the standard obviously is broken . With a lot of support by most of the committee and actual work by a couple of people there is a paper that aims to fix it. The only people who never constructively helped but still vote against this important repair is your block of other non-contributing people you are part of: https://github.com/c-lang-org/polls/blob/main/n3909.md
(Also a counter proposal would be constructive.)
uecker 2 hours ago [-]
But I apologize, I should not be so negative. But I hope you see where the frustration comes from. The cleanup efforts are driven by a lot of volunteer work. We could use any help and instead of people just voting against such works.
Joker_vD 3 hours ago [-]
> My guess is that it has to do with signed-magnitude representation causing left shifts to be absolute garbage with negative numbers.
First of all, why not make it implementation-defined? That seems rather more useful for the programmer. Second, I'm personally aware of only a single machine with signed-magnitude representation, IBM 7090, and its ALS (Accumulator Left Shift) instruction treated the sign bit as sticky; amusingly, LGL (Logical Shift Left) did as well, so you had to put the value being shifted into the MQ register, not the accumulator, when you wanted an unsigned shift. So... no, that can't be it?
jcranmer 3 hours ago [-]
One of the tricky things is that undefined behavior is commonly understood as having an unlimited "blast radius" and implementation-defined behavior is commonly understood as not permitting that kind of "blast radius." So any extension point that needed that unlimited "blast radius" had to be undefined behavior. (This has changed somewhat in modern times, but it does hold a little bit today--I'd point you to the discussion of N3863 at the most recent meeting, but I don't have any minutes that I feel really captured that discussion well enough.)
And one of those kinds of "blast radius" is traps, and I suspect the original motivation for making signed integer overflow undefined behavior was precisely to preserve the ability to trap on signed integer overflow, which couldn't be implementation-defined. But the records of the discussions leading up to C89 and C99 are just too fragmentary for me to be certain.
userbinator 2 hours ago [-]
The problem with UB, as evidenced over the years, is that it causes compiler writers to drift much too far from reality, despite the standard itself suggesting "behaving [...] in a documented manner characteristic of the environment" as one of the (better) choices.
Joker_vD 2 hours ago [-]
> And one of those kinds of "blast radius" is traps,
Wait. An implementation-defined behaviour isn't allowed to be trap/termination of execution? Okay, make it unspecified then, with the options of trapping or calculating some unspecified (not indeterminate) integer value.
> N3863
Hm?
Because implementation-defined behavior relies on the definition of unspecified behavior, it
means that implementation-defined behavior requires two or more possibilities to be defined in
the standard. However, a brief look at its uses in the standard clearly shows that there isn’t
always a list of potential behaviors to pick from.
Eh, I'd argue that omission of such a list is merely an implicit infinite ("two or more", you know) list of possibilities, its construction being self-evident.
N3783 5.2.1.2p1.1: Physical source file multibyte characters are mapped, in an implementation-
defined manner, to the source character set (introducing new-line characters for end-of-line
indicators) if necessary.
There is an infinite list of possible ways to map multibyte characters to the source character set — an implementation has to pick one and document it.
N3783 5.2.1.3p1: A conforming implementation shall produce at least one diagnostic message
(identified in an implementation-defined manner)
There is an infinite list of possible diagnostic messages...
N3783 5.2.2.2p1-2: In a freestanding environment (in which C program execution can take
place without any benefit of an operating system), the name and type of the function called at
program startup are implementation-defined.
There is an infinite list of possible C identifiers that an implementation may chose as the name of the function to call at program startup.
jcranmer 2 hours ago [-]
N3863 is one of those papers where what the paper proposed and what was actually discussed in the meeting ended up being rather different things, and it's the meeting discussion that I'm pointing to, not the paper itself.
> Wait. An implementation-defined behaviour isn't allowed to be trap/termination of execution? Okay, make it unspecified then, with the options of trapping or calculating some unspecified (not indeterminate) integer value.
Unspecified behavior also isn't allowed to be a trap. The difference between unspecified and implementation-defined is whether or not the compiler has to document its choice; the difference between unspecified and undefined is whether or not the choice is limited.
SAI_Peregrinus 4 hours ago [-]
I think it means what you think is ridiculous. Shifting the sign bit out is UB. Unrepresentable results are UB.
Joker_vD 4 hours ago [-]
> Shifting the sign bit out is UB
Shifting into the sign bit is also UB. Can I please have a language that actually has bitwise operators with defined semantics? No CPUs had differentiated between SAL/SHL for more than 30 years, if that was the original justification.
I'm fine with left shift trapping on overflow. I'm fine with it just wrapping around. I'm even fine with bitwise shifts simply unapplicable to ints ("cast to unsigned first, then cast back to int"). I am not fine with an operator that invokes UB for literally half of the values of the lhs's domains.
uecker 3 hours ago [-]
I was thinking about eliminating this shift-into-left bit UB. There was a previous attempt though that failed to get consensus. (but long enough ago that one could try again).
But all this signed overflow UB can be turned into traps using sanitizers.
In practice, generally mandating a trap is difficult though in ISO C. My plan is to mandate this as part of a special mode, in which case I would just leave this UB in the main standard.
(One problem we also have that some special interests groups in WG14 are rather hostile to our work and the rest of the C community - so I encourage everybody who is actually using C and caring about it to join).
Joker_vD 2 hours ago [-]
> I was thinking about eliminating this shift-into-left bit UB.
At least make it "change of the sign bit is UB" — if 0 shifts into the sign-bit of a positive number, or 1 shifts into the sign-bit of a negative number, that shouldn't be UB. This would make left-shifts of negative numbers well-defined, their behaviour being that of two's complement numbers. And C23 already demands two's complement from the implementations, doesn't?
> signed overflow UB can be turned into traps using sanitizers.
Well, yeah, sure, but shifting -1 one place to the left doesn't overflow, it produces -2; only shifting INT_MIN or something up to and including INT_MIN + (INT_MAX/2) would overflow.
I always took those to mean "we're sure a bunch of you are already using the keyword we wanted to use as typedef in your codebase, so here's something that's in the standard's namespace, and you can typedef it to something sane for your codebase".
uecker 3 hours ago [-]
Indeed. And those typedefs were even provided by including stdbool.h
C23 broke a lot of code by making this proper lower case keywords, we probably should have waited longer.
pjmlp 2 hours ago [-]
It doesn't get rid of _Really_Hate_This, only for a few that already have enough years behind them, the process for new keywords remains the same.
Bounded checked slices like proposed by Dennis Ritchie, or Walter Bright, remains a pipe dream.
201984 7 hours ago [-]
>post c99 additions being pointless
Atomics are necessary nowadays though.
3836293648 6 hours ago [-]
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.
aw1621107 6 hours ago [-]
> 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.
Yeah, it's all fun and games until you realize that you compiler may invent writes in order to eliminate a branch. Which is rather nonsensical, when you stop to think about it — surely an additional store to global can't be faster than a mispredicted branch?
homosapien97 3 hours ago [-]
Branch mispredictions on deep machines can be devastating, whereas a store can hit in your L1. Storing can definitely be faster than a mispredicted branch if you think you'll hit in your L1/L2
adgjlsfhk1 3 hours ago [-]
store to a global is typically 0 cycles (although subsequent reads may be slowed down)
jcranmer 6 hours ago [-]
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.
publicmail 6 hours ago [-]
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.
2 hours ago [-]
dokyun 2 hours ago [-]
Funny this is getting downvoted cause it's literally what Plan 9 C does.
I don't think that man page on its own is sufficient to draw that particular conclusion. You need compiler/language support to ensure atomics are handled properly, so you'd need to know how Plan 9's compiler/language specifies atomics.
hollowonepl 3 hours ago [-]
As much as I’m sentimental about C/C++ myself, changing language spec every 3 years is not what I call standards
pjmlp 2 hours ago [-]
Plenty of industry standards change every few years, that is why a date is part of their identification number.
uecker 3 hours ago [-]
It does not change every 3 years for C: C99, C11, C17 (minor cleanup), C23.
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 :)
“ISO C language standard requires that C compilers support the following three pragmas, and some C++ compiler vendors support them, to varying degrees, in their C++ frontends:
where arg is either ON, OFF, or DEFAULT.”⇒ it seems C compilers must support this (but C++ compilers need not)
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.
(D sez `char` is unsigned. No more nonsense!)
C also needs to implement proper arrays. D does it, and that one feature is worth its weight in gold:
https://www.digitalmars.com/articles/C-biggest-mistake.html
It's sooo nice to not have array overflows anymore.
In what concerns C itself, as the language authors, they did not care that much about the standard, hence why it is mostly C89 with Rob Pike ideas on how header files should be organised, and other Plan 9 specific idioms.
* 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, 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: (-1) << 1 is UB?!That's exactly what it means, see the change mentioned in https://www.open-std.org/jtc1/sc22/wg14/www/docs/n723.htm. (Previously, in C89, left shift on signed integers was completely undefined, only unsigned integers had a defined left-shift operation.) My guess is that it has to do with signed-magnitude representation causing left shifts to be absolute garbage with negative numbers. You also have to remember that the standard having undefined behavior doesn't preclude implementations from defining that behavior, and this is especially true with the freewheeling nature of a lot of the original undefined behavior introduced in C89 and C99.
> Also, C23 (and C2y) is moving ever closer to actually having defined semantics.
Eh, having seen how some of the sausage gets made, there's definitely been some cases where the overeager urge to rip out undefined behavior from the standard has worsened the quality.
I also do not see where the quality suffered. There were some rather minor issues we created and need to cleaned up.
This kind of attitude tends to make me suspect that you are disinclined to actually listen to my feedback.
(Also a counter proposal would be constructive.)
First of all, why not make it implementation-defined? That seems rather more useful for the programmer. Second, I'm personally aware of only a single machine with signed-magnitude representation, IBM 7090, and its ALS (Accumulator Left Shift) instruction treated the sign bit as sticky; amusingly, LGL (Logical Shift Left) did as well, so you had to put the value being shifted into the MQ register, not the accumulator, when you wanted an unsigned shift. So... no, that can't be it?
And one of those kinds of "blast radius" is traps, and I suspect the original motivation for making signed integer overflow undefined behavior was precisely to preserve the ability to trap on signed integer overflow, which couldn't be implementation-defined. But the records of the discussions leading up to C89 and C99 are just too fragmentary for me to be certain.
Wait. An implementation-defined behaviour isn't allowed to be trap/termination of execution? Okay, make it unspecified then, with the options of trapping or calculating some unspecified (not indeterminate) integer value.
> N3863
Hm?
Eh, I'd argue that omission of such a list is merely an implicit infinite ("two or more", you know) list of possibilities, its construction being self-evident. There is an infinite list of possible ways to map multibyte characters to the source character set — an implementation has to pick one and document it. There is an infinite list of possible diagnostic messages... There is an infinite list of possible C identifiers that an implementation may chose as the name of the function to call at program startup.> Wait. An implementation-defined behaviour isn't allowed to be trap/termination of execution? Okay, make it unspecified then, with the options of trapping or calculating some unspecified (not indeterminate) integer value.
Unspecified behavior also isn't allowed to be a trap. The difference between unspecified and implementation-defined is whether or not the compiler has to document its choice; the difference between unspecified and undefined is whether or not the choice is limited.
Shifting into the sign bit is also UB. Can I please have a language that actually has bitwise operators with defined semantics? No CPUs had differentiated between SAL/SHL for more than 30 years, if that was the original justification.
I'm fine with left shift trapping on overflow. I'm fine with it just wrapping around. I'm even fine with bitwise shifts simply unapplicable to ints ("cast to unsigned first, then cast back to int"). I am not fine with an operator that invokes UB for literally half of the values of the lhs's domains.
But all this signed overflow UB can be turned into traps using sanitizers. In practice, generally mandating a trap is difficult though in ISO C. My plan is to mandate this as part of a special mode, in which case I would just leave this UB in the main standard.
(One problem we also have that some special interests groups in WG14 are rather hostile to our work and the rest of the C community - so I encourage everybody who is actually using C and caring about it to join).
At least make it "change of the sign bit is UB" — if 0 shifts into the sign-bit of a positive number, or 1 shifts into the sign-bit of a negative number, that shouldn't be UB. This would make left-shifts of negative numbers well-defined, their behaviour being that of two's complement numbers. And C23 already demands two's complement from the implementations, doesn't?
> signed overflow UB can be turned into traps using sanitizers.
Well, yeah, sure, but shifting -1 one place to the left doesn't overflow, it produces -2; only shifting INT_MIN or something up to and including INT_MIN + (INT_MAX/2) would overflow.
> The << operator performs a smart shift, which defines a result for a shift of any value.
> - Using a negative value for rhs performs a right shift using abs(rhs).
> - Using a value for rhs that is greater than or equal to the bit width of lhs is an overshift, resulting in zero.
> - Using any other value for rhs performs a left shift on lhs by that amount.
And while the docs don’t say it, `Int.max << 1 == -2`. And in fact, `T.max << 1 == -2` for all `T: BinaryInteger`.
I always took those to mean "we're sure a bunch of you are already using the keyword we wanted to use as typedef in your codebase, so here's something that's in the standard's namespace, and you can typedef it to something sane for your codebase".
C23 broke a lot of code by making this proper lower case keywords, we probably should have waited longer.
Bounded checked slices like proposed by Dennis Ritchie, or Walter Bright, remains a pipe dream.
Atomics are necessary nowadays though.
Not that I'd want it, I like complex type systems, but I see it as philosophically consistent with C.
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...
And, FWIW, in a lot of high-performance code, the overhead of a function call may be too high for an atomic operation.
https://man.cat-v.org/plan_9/2/atom