Re: Making --with-wide-int the default

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden
>> Date: Sun, 15 Nov 2015 17:01:40 +0100
>> 
>> Here is another data point: the code base seems woefully unprepared to
>> actually deal with the resulting ranges.
>> 
>> Lisp integers are only converted with macros XINT and XFASTINT as far as
>> I can tell, and
>> 
>> git grep XINT
>> 
>> shows lots of assignments to variables of type int rather than
>> EMACS_INT.
>
> If these are real problems, they should have bitten us long ago, in
> the 64-bit builds, no?

Why?  They'll only trigger for cases that exceed a range of 32 bits, and
if those cases were other than rare, they'd have rendered the 32-bit
builds (which work with 30-bit precision) unusable.

However, we never previously had the case that a number which looks fine
in Lisp does not transfer into C properly.

> There were, indeed, such problems, which prevented using buffers
> larger than 2GB, but they were solved long ago, when a significant
> portion of our users moved to 64-bit machines.
>
>> I think that there should be macros XINT, XUINT, XEINT (for
>> EMACS_INT) which trigger a range error when the value does not fit
>> the respective range.
>
> Could be a valuable debugging aid, I think.

Well, it's probably worth checking what Guilemacs' idea about XINT is
since Guile _does_ seamlessly degrade into arbitrary precision integers
when exceeding integer precision.  So much of the work for supporting
arbitrary integers (and converting from Guile/Elisp integers to C
integers and back) should probably be in the Guilemacs branch already
and there'd be little point in reinventing it separately.

-- 
David Kastrup