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

[Vinay Sajip]

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.

Is this a known issue? I just thought I'd mention it here before opening an
issue on the tracker (I didn't find any existing issue covering this).

It seems reasonable to interpret any value given as a literal negative value
(or where the value fits in a signed int) as an integer, but interpret as
unsigned any value provided in hex or using shift and binary logic operators,
such as &, | and ^.

Thanks,

Vinay Sajip