Re: integer overflow handling for most-negative-fixnum

[Andy Moreton <andrewjmoreton@gmail.com>]

On Fri 20 Jul 2018, Paul Eggert wrote:

> On 07/18/2018 07:39 PM, Andy Moreton wrote:
>> Why are non-base10 numbers treated as signed ?
>
> Emacs fixnums are signed; there is no 'unsigned' type in Emacs Lisp. Although
> we could of course add such a type, it'd be better to expend our limited
> development resources on adding bignums.

Bignums are not relevant to this discussion. Non base10 representations
of emacs fixnums are not treated consistently, and prevent round trip
handling of the full range of valid fixnum values.

> The 'unsigned' type in C has been a glitch magnet.

I disagree: it depends on what you are doing. Signed types cause fewer
problems for arithmetic, but unsigned types are essential for bit
twiddling of hardware register values. Problems usually arise from
mixing signed and unsigned types in the same expression.

> It might perhaps be useful to add an Emacs Lisp syntax for negative
> hexadecimal numbers, e.g., -#x10 would be equivalent to -16.

As noted later in this thread, #x-10 is valid syntax for this value.

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

If the reader will not accept #x2000000000000000 as input then the value
of most-negative-fixnum as a non base10 number octal should have
negative sign to ensure consistent handling.

Either the print routines or the reader have a bug.

    AndyM