PR# 11276 {INTEGER_8} 0xff accepted but should be "integer too large" error

The expression {INTEGER_8} 0xff is accepted but should not be since 255 is too
large for INTEGER_8.  Instead, it seems to be interpreted as -1.  
{INTEGER_8} -0xff is correctly rejected as being too small for INTEGER_8.
The smallest value accepted for INTEGER_8 is -0x80 (-128) which is correct.

Other sized INTEGER variants have the same problem.

See attached class.

A final comment before letting the ECMA committee decides. The standard defines that the integer representation is done in two's complement. If not specified, then it is an oversight because we had discussions about it in the committee.

That code (i8 := 0xFF) should not be accepted, though n8 := 0xFF should.
If you want to deal with bit patterns, isn't that what naturals are for?

Note also that "the bit pattern of the integer" is not well-defined anyway,
since there are several possible representations of an integer
(ones complement, twos complement, sign magnitude).  See for example

   http://nssdc.gsfc.nasa.gov/nssdc/formats/IntegerNumbers.htm

If your code is really dealing with integers and you specify 0xFF
and it is interpreted as a bit pattern, then you won't get the value
you expect on a ones-complement machine.  Unless you mean that the compiler
is interpreting 0xFF as a bit pattern in two's complement notation,
in which case you would get the expected value of -1.

But again, I think having the semantics of a constant depend on context
is a very bad idea.  Anyway, I'll let the ECMA committee sort this out.

But then code that we used to accept:

i8 := 0xFF

would not be valid anymore. We chose to rely on the actual bit representation of the integer rather than on its value.

I'm not sure it makes that much sense to have -0xFF has a constant value, it is simply the prefix "-" applied to a value of 0xFF. which is different. I guess we have to review ECMA to be more compliant with what we do since I believe it makes more sense.

I don't agree.  I believe ECMA specifies that an Integer (no sign)
can be written in decimal, hexadecimal or octal, with the same
semantics.  Therefore 0xFF is 255.  It is only at the level of
Signed_integer (or whatever it is called) that the sign comes into
play.

Note also that in rev 68843

   print ({INTEGER_8} 0xFF)      prints -1
   print ({INTEGER_8} -0xFF}     gives integer too large compile error

I don't think it is the intention of ECMA that the value of 0xFF
depend on the context.  I think it is always 255.  Please see
section 8.32.30 for the semantics of Integer.

I'm not sure to agree here, the hex representation of -1 is 0xFF so accepting {INTEGER_8} 0xFF simply means that you mean -1.

I haven't found anything in ECMA that says an Integer expressed in hexadecimal
is any different than an Integer expressed in decimal.  See section 8.32.30
for semantics of an Integer.  But the compiler gives a syntax error for

   {INTEGER_8} 255

and (correctly in my view) says that the value is too large for INTEGER_8.
Surely the same error should be issued for

   {INTEGER_8} 0xff

which is identical to the first expression except that hexadecimal notation
is used for the Integer.

I'm not sure if it is an ECMA specification, but for hexadecimal constants, we do not care about their value, but about the size of the data. And 0xFF is small enough to fit in an INTEGER_8.

Now for the negative variants of hexadecimal value, we do check the value and thus report the error.

Attachments for problem report #11276