[cfe-dev] libclang - inconsistent signs for enumeration constants

[John McCall]

On Sep 15, 2011, at 12:02 PM, Vinay Sajip wrote:

> Given the source
> 
> enum ABC {
>    V1 = 1,
>    V2 = 0x90000100
> };
> enum DEF {
>    V3 = 1,
>    V4 = -100
> };
> enum GHI {
>    V5 = 1 << 28,
>    V6 = 12 << 28
> };
> 
> The libclang API returns inconsistent signs for the different
> enumeration constants. On a 32-bit machine, The EnumConstantDecl for the
> various values have the following types:
> 
> V1 - Int - as expected
> V2 - UInt - seems reasonable, though it's negative if viewed as a 32-bit int
> V3 - Int - as expected
> V4 - Int - as expected
> V5 - Int - seems reasonable
> V6 - Int - not consistent with the interpretation of V2.
> 
> Both V2 and V6 have bit 31 set, yet one is interpreted as unsigned and the
> other as signed.

This is dictated by C.

The initializer in V2 is unsigned because the integer literal 0x90000100 falls outside of the range of a signed int (C99 6.4.4.1p5).
The initializer in V6 is signed because 12 does not fall outside of the range of a signed int (6.4.4.1p5 again), and left-shifting a signed int doesn't change its type (6.5.7p3).  Also, technically, left-shifting into the sign bit like this is undefined behavior (6.5.7p4).

John.