parseHexInt doesn't check the value's length.

[kayabaNerve]

parseHexInt, from strutils, doesn't check the hex value's bit length. If the sign bit is set (assuming a naive byte case), parseHexInt will return negative numbers. If the value's length is too long, only the last bytes of it are read, ignoring the first.

Example

import strutils
echo parseHexInt("0xFFFFFFFFFFFFFFFF")
echo parseHexInt("0xFF00FFFFFFFFFFFFFFFFFF")

Current Output

-1
-1

Expected Output

A ValueError, and if execution wasn't halted, yet another (or at least a RangeError).

Possible Solution

Validate input length doesn't exceed the int size limit/if the sign bit was set.

$ nim -v
Nim Compiler Version 1.4.4

[timotheecour]

• related:

let a = 0xFF00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

compiles, but shouldn't

• parseutils.parseHex seems buggy too

• check also parseOctInt + friends

• the proc seems error prone, because behavior for negative int's is arbitrary (should it raise? should it not?), how about deprecate it in favor of parseHex[T: SomeUnsigned](U: typedesc[T]): U, which is self-documenting, and more flexible; if user wants an int, they can cast

[ringabout]

Related:
#4350

[kayabaNerve]

@timotheecour I wouldn't say this behavior is arbitrary; if the hex is treated as bytes, it's valid behavior to turn negative. If the hex is treated as an integer though, as the name states, no signage should be applied. Moving to a pure unsigned type entirely would definitely resolve this though.

Also, to comment on the use case in which this came up, due to the linking of #4350 whose first comment dismisses hex checking, it's not even any low-level sys task. I'm reading HTTP bodies. Streamed requests use the chunked transfer encoding which denotes length in hex. While receiving > 2 GB of data in a chunk is completely infeasible, this would claim it's < the max length (and then break on receiving said chunk).

[Araq]

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