|
From: | Paul Eggert |
Subject: | Re: integer overflow handling for most-negative-fixnum |
Date: | Fri, 20 Jul 2018 15:10:07 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
On 07/18/2018 07:39 PM, Andy Moreton wrote:
+ (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.
Here, the code is executing something like (read "#x2000000000000000"), which is indeed out of range for a fixnum, since fixnums are signed and go up only to #x1fffffffffffffff (on 64-bit hosts).
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. The 'unsigned' type in C has been a glitch magnet.
It might perhaps be useful to add an Emacs Lisp syntax for negative hexadecimal numbers, e.g., -#x10 would be equivalent to -16.
Why does the error message ignore the base of the input value ? It should give a more accurate description of the problematic input.
Yes, it should. I'll see if I can pry loose some time to look into that.
[Prev in Thread] | Current Thread | [Next in Thread] |