Report an error for certain large unsigned enumeration constants.

Enumeration constants must have values representable as an int (i.e. 16-bit signed values, in ORCA/C), but errors were not being reported if code tried to use the values 0xFFFF8000 to 0xFFFFFFFF. This problem could also affect certain larger values of type unsigned long long. The issue stemmed from not properly accounting for whether the constant expression had a signed or unsigned type.

This sample code demonstrated the problem:

enum E {
        a = 0xFFFFFFFF,
        b = 0xFFFF8000,
        y = 0x7FFFFFFFFFFFFFFFull,
        z = 0x8000000000000000
};

Parser.pas

@@ -3091,6 +3091,10 @@ while token.kind in allowedTokens do begin
                   Expression(arrayExpression,[commach,rbracech]);
                   enumVal := long(expressionValue).lsw;
                   if enumVal <> expressionValue then
+                     Error(6)
+                  else if enumVal < 0 then
+                     if expressionType^.kind = scalarType then
+                        if expressionType^.baseType in [cgULong,cgUQuad] then
                            Error(6);
                   end; {if}
                tPtr^.eval := enumVal;   {set the enumeration constant value}

cc.notes

@@ -1194,6 +1194,8 @@ int foo(int[42]);
 
 156. The second subexpression of a ? : expression may use the comma operator, even in a context where commas would otherwise separate items (such as arguments to a function).  For example, abs(1 ? 2,-3 : 4) is a valid call that passes one argument.  Code like this was causing spurious errors, but now it is accepted.
 
+157. An error was not reported if code tried to declare an enumeration constant with a value in the range 0xFFFF8000 to 0xFFFFFFFF.  (Enumeration constants are limited to values representable as an int.)
+
 -- Bugs from C 2.1.0 that have been fixed -----------------------------------
 
 1.  In some situations, fread() reread the first 1K or so of the file.