No checking when a hexadecimal integer constant is too large for its type

[edubart]

The following code:

let a = 0x0123456789abcdefffffffffffffffff
let b = 0xffffffffffffffff
echo $a
echo $b
echo (a == b)

Outputs:

-1
-1
true

What I was expecting:
An error because 0x0123456789abcdefffffffffffffffff is not a valid number as it's too large.

[Araq]

Not's not a really bug, we decided to not check hexadecimal literals because people who think in hex also don't think about edge cases or correctness or overflows and in general don't want to be bothered with such details.

[abudden]

As someone who works in hex and thinks in hex an awful lot, I spend a lot of time thinking about edge cases, correctness and overflows and I certainly want to be bothered with such details. In C, if I'm dealing with 32-bit values and I accidentally enter:

uint32_t xyz32 = 0x1234567A8U;
uint64_t xyz64 = 0x123456781234567A8ULL;

I'd be a bit upset if the compiler and static analyser didn't spot the obvious typos (GCC says warning: large integer implicitly truncated to unsigned type [-Woverflow] for the 32-bit case and integer constant is too large for its type for the 64-bit case).

When I read this issue, I wondered if it was because the type wasn't defined (which would be relatively unusual in my world of hexadecimal as it is commonly associated with microcontroller peripherals with individual bits set for different functions and the number of bits is critical). I assumed that if the type was defined then the C compiler would provide the warning message even if Nim didn't. However, having just tested this with a slightly modified version of @edubart's code, I still don't get an error message:

let a: uint64 = 0x0123456789abcdefffffffffffffffff.uint64
let b: uint64 = 0xffffffffffffffff.uint64
echo $a
echo $b
echo (a == b)

It looks like Nim silently edits the code to remove the numbers that were added erroneously and produces code that the C compiler is happy with (setting both a and b to 18446744073709551615ULL in my example). While I don't really want to see C error messages in place of Nim ones I really really don't want Nim to change the constants in my code from what I've specified with no indication that it has done so. Note that in the above example, using 'u64 notation instead of .uint64 produces the same result.

On a positive note, however, this seems to only be a problem with 64-bit integers. The code:

let c: uint32 = 0x1234567A8.uint32
let d: int32 = 0x1234567A8

Produces conversion from int64 to uint32 is invalid for the first line and type mismatch: got (int64) but expected 'int32' for the second one. Hence in most applications associated with a current microcontroller (which are usually 32 bits or fewer), there would be some protection where the type is specified.

[krux02]

well I guess implementing a check is pretty easy. The literal doesn't even need to be parsed. More than 16 hex digits for 64 bit integer? → error

[Araq]

I wasn't all that serious when I wrote this and left the bug open for a good reason. My apologies.