integer overflow handling for most-negative-fixnum

[Andy Moreton]

The patches for bug#30408 contained this testcase:

> +(ert-deftest read-large-integer ()
> +  (should-error (read (format "%d0" most-negative-fixnum))
> +                :type 'overflow-error)
> +  (should-error (read (format "%+d" (* -8.0 most-negative-fixnum)))
> +                :type 'overflow-error)
> +  (should-error (read (substring (format "%d" most-negative-fixnum) 1))
> +                :type 'overflow-error)

These tests are all reasonable, as these numbers are definitely out of
fixnum range.

> +  (should-error (read (format "#x%x" most-negative-fixnum))
> +                :type 'overflow-error)
> +  (should-error (read (format "#o%o" most-negative-fixnum))
> +                :type 'overflow-error)

However, these tests (and the overflow behaviour) seem completely wrong
to me. The reported error is for an out of range fixnum, when what was
tested was an explicitly valid integer value.

Why are non-base10 numbers treated as signed ? Why can they not be
treated as unsigned, so the hex and octal values can be read as valid
input ?

ELISP> most-negative-fixnum
-2305843009213693952 (#o200000000000000000000, #x2000000000000000)
ELISP> -2305843009213693952
-2305843009213693952 (#o200000000000000000000, #x2000000000000000)
ELISP> #o200000000000000000000
*** Read error ***  Arithmetic overflow error: "200000000000000000000 is out of 
fixnum range; maybe set ‘read-integer-overflow-as-float’?"
ELISP> #x2000000000000000
*** Read error ***  Arithmetic overflow error: "2000000000000000 is out of 
fixnum range; maybe set ‘read-integer-overflow-as-float’?"

Why does the error message ignore the base of the input value ? It
should give a more accurate description of the problematic input.


    AndyM