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

[Eli Zaretskii]

> From: David Kastrup <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden
> Date: Sun, 15 Nov 2015 21:42:24 +0100
> 
> 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?

Because an int is a 32-bit data type in 64-bit builds as well.  So if
we use XINT to assign to an int, and the value exceeds INT_MAX, the
same problems will happen in both 64-bit builds and in 32-bit builds
with wide ints.

> 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.

The same considerations apply to 64-bit builds.

My point is that these issues, if they exist, are not unique to the
32-bit builds with wide ints, they are with us even without wide ints.

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

Once again, if we assign an Emacs integer to a C int, we will have the
same problems in 64-bit builds.

Btw, it's not like we live dangerously there: these issues were
extensively scrutinized several years ago, when we lifted the 2GB
limit on buffers in 64-bit builds, and all the relevant code was
carefully audited and fixed.  It is, of course, possible that some new
problems crept in, but the basis is sound, both for the 64-bit build
and the 32-bit build with wide ints.

Bottom line: I don't think there are new problems the 32-bit build
with wide ints introduces that aren't with us in the 64-bit builds.