Re: [Dotgnu-libjit] [Patch] Type conversion bug

[Michele Tartara]

2010/10/13 Klaus Treichel <address@hidden>:
> Hi Michele,
>
[...]
> This is not a bug.
> In libjit we follow the C conversion standard.
> So the sign extension or zero extension depends on the source type for a
> widening conversion.
> A signed 32bit is always sign extended to 64bit even if the target type
> is unsigned.

Mmmh... I'm sorry, but I do not agree.

I have an int32 with value 0xffffffff that has to be converted to a uint64.

According to C99 standard
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf), paragraph
"6.3.1.3 Signed and unsigned integers", page 55, the conversion is the
following:
"[...]if the new type is unsigned, the value is converted by
repeatedly adding or
subtracting one more than the maximum value that can be represented in
the new type
until the value is in the range of the new type."

Therefore, the new type is uint64. The maximum number that can be
represented in that type is 0xffffffffffffffff. I add 1 to that value
and obtain 0x10000000000000000, that is "one more than the maximum
value that can be represented in the new type".
Now, I add this -arithmetically, as specified by note 49 in the
standard- to the value to be converted and I obtain:

0x10000000000000000 + 0xffffffff = 0x100000000ffffffff.

Therefore, I discard the leading "1" (that is the carry bit) and I
obtain 0x00000000ffffffff, that is what I expect: the conversion to
64-bit WITHOUT sign extension, as opposed to what you suggest (sign
extension depending on the source type).

Did I miss something? Or is my reasoning correct?

Cheers,
Michele