Re: Strange enum type conversion

[Andrew Haley <aph at redhat dot com>]

John (Eljay) Love-Jensen wrote:
> Hi Andrew,

Hi

>> Isn't [(1 << 31)] UB on a 32-bit machine as well?  Looks like integer overflow
> to me.
> 
> You know... I'm not sure.
> 
> I thought (1 << 31) was defined behavior on 2's and 1's complement machines.
> I was an assembly bit-twiddler (6502, 65816, 680x0, and just a little bit of
> 80x86) back in the 70's and 80's (and some Alpha, PowerPC, and SPARC in the
> 90's... but not enough to brag about), so I tend to think in rather skewed
> terms (e.g., I think of C as a powerful macro assembler).
> 
> But now that you brought it up*, I can't say that with strong confidence.
> I'll have to research C (ISO 9899) and C++ (ISO 14882).

It's explicitly undefined: 6.5.7 Para. 4.

> * Given the recent discussion about certain optimizations which perform
> compilation analysis and do certain /a priori/ compiler knowledge range
> optimizations based on UB that were a surprised** to the developer (the
> "surprise" fixed by -fwrapv).

Yes, but there are a fair few loop optimizations that are disabled by
-fwrapv, so in general it's much better to write in C, not some semi-
broken version of it.

Everyone sing!

When I find my code in tons of trouble,
Friends and colleagues come to me,
Speaking words of wisdom:
"Write in C."

As the deadline fast approaches,
And bugs are all that I can see,
Somewhere, someone whispers:
"Write in C."

Write in C, Write in C,
Write in C, oh, Write in C.
LOGO's dead and buried,
Write in C.

...

     -- Brian Marshall, 1987

Andrew.