i think you need to make sure it's unsigned so that sign extension has no chance of occurring, so my money is on 1U << 31?

wore it with pride, but the pride was misplaced

But also, I just wished C would mandate that constants are just assumed to be of the "expected" type, because in 99.999999% of all cases a programmer really meant the obvious thing with "uint64_t x = 1 << 31".

But I guess we'll just keep those horrible semantics C has in a couple of areas, because nobody want to fix those things, because "it could break things".

I believe it would work as expected with:

1U << 31;

The unexpected part is that sign extension from 32 to 64 bits takes place before reinterpretation to unsigned. The C99 standard is admittedly opaque on this point. If you make the rvalue unsigned as well, then you get the (presumably) expected result.

(Just tested it with GCC 13.3 -- it works.)

It’s UB in the general case because, if the operand is not a constant, you want to lower it to a shift instruction but C works with targets that have different number representations. Ones or twos complements, or explicit sign bits are all permitted, but all of these will give different behaviours if you flip the top bit.

For wider shifts, different ISAs had different semantics for shifts wider than the register, so C made that fully undefined.

This combination lets you lower source-level shifts to a shift instruction.

C also doesn’t mandate that this be constant evaluated unless the result is used as a constant, so there’s no way to force implementations to diagnose the UB at compile time for this case. But, as a QoI issue, it is permitted and compilers should.

Like it's just a design bug really. And no matter how much this is UB or not won't change that.

It was not UB in C90. That is why it was UB without ubsan ...

Like there is UB and then there is UB.

Like any new language doing that today would be considered broken on arrival.