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
};
This commit is contained in:
Stephen Heumann 2021-07-07 20:06:05 -05:00
parent ae45bd4538
commit fbdbad1f45
2 changed files with 7 additions and 1 deletions

View File

@ -3091,7 +3091,11 @@ while token.kind in allowedTokens do begin
Expression(arrayExpression,[commach,rbracech]);
enumVal := long(expressionValue).lsw;
if enumVal <> expressionValue then
Error(6);
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}
enumVal := enumVal+1; {inc the default enumeration value}

View File

@ -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.