There's so many times where I realise what I thought was simple in C turns out to be a minefield. I'd assumed an enum was 'word' sized, so 64 bits on a 64 bit architecture, but instead it turns out to be unspecified, and left up to the compiler.
Thinking through the standards quote again, I'm not sure that MSVC's behaviour is even wrong (when not using C23 type specification)? Because it doesn't look like it's required that the underlying type has to be sufficient to represent the largest enum. So maybe it's not wrong, it's just ... broken.
There's so many times where I realise what I thought was simple in C turns out to be a minefield. I'd assumed an enum was 'word' sized, so 64 bits on a 64 bit architecture, but instead it turns out to be unspecified, and left up to the compiler.
Thinking through the standards quote again, I'm not sure that MSVC's behaviour is even wrong (when not using C23 type specification)? Because it doesn't look like it's required that the underlying type has to be sufficient to represent the largest enum. So maybe it's not wrong, it's just ... broken.
What happens if the constant had an explicit type, or something like 4294967296ULL?
Could it be that the compiler is just interpreting the large number as a signed type that has wrapped around?
Has anyone raised the issue with MS to see what they have to say about it?