Re: [DotGNU]Pnet signed int bugs

[Rhys Weatherley]

Peter Minten wrote:
> 
> Hi folks,
> 
> there seem to be some bugs in pnet's signed int code, the following example
> demonstrates the problem:
> 
> class test
> {
>     public static void Main()
>     {
>         Console.WriteLine(Int16.MinValue == 0x8000);
>         //Should return true according to specs

Microsoft's compiler returns false.  The two values
are implicitly coerced to "int" before applying the
"==" operator.  When coerced, you get 0xFFFF8000 and
0x00008000, which are not equal.

>         Console.WriteLine(Int32.MinValue == 0x80000000);
>         //Should return true

Microsoft's compiler returns false.  Similiar problem,
except that this time 0x80000000 is of type "uint", so
they are both coerced to long: 0xFFFFFFFF80000000 and
0x0000000080000000.  Whenever "==" is applied, it will
always coerce to the smallest type that can represent
both values exactly: "long" in this case.

>         Console.WriteLine(Int64.MinValue == 0x8000000000000000);
>         //Doesn't even compile but should return true according to specs

Microsoft's compiler also gives an error, as the constant
is of type ulong, not long.  You cannot compare long
and ulong without an explicit cast, as there is no
common type that can exactly represent both values.

In each of the three cases, if you insert an explicit
cast of the constant to short, int, or long, it will
give the behaviour you expected.

The behaviour of cscc is consistent with MS'es compiler,
and with the spec.  I'm curious as to which section of
the spec you saw this in, as I implemented the coercion
rules from the spec.

There _are_ some signed/unsigned bugs in cscc.  If you
use the number 3 in an unsigned context, it should work,
but right now there are contexts where cscc thinks that
3 has the type int, which cannot be implicitly converted
to uint.  So an explicit cast is required.  I need to
overhaul the handling of constants during semantic
analysis to fix this.

Cheers,

Rhys.