emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Kastrup
Subject: Re: Making --with-wide-int the default
Date: Sun, 15 Nov 2015 17:01:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Richard Stallman <address@hidden>
>> CC: address@hidden, address@hidden, address@hidden,
>>      address@hidden
>> Date: Fri, 13 Nov 2015 17:03:10 -0500
>> 
>>   >   I think it is quite reasonable _not_ to use wide ints by
>>   > default on architectures with a 32-bit address space.
>> 
>> +1.
>
> Faced with such powerful opposition, I guess this now becomes your
> decision, John.  I can always build my own Emacs with that option; the
> question is what we want for the majority of our users on 32-bit
> systems.

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.  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.  Possibly also XLONG and XULONG but I'm not sure we
actually have platforms where long/int are different.

Some of those uses may well be security problems.  Using EMACS_INT
everywhere might be inappropriate (where's the point in having array
indexes longer than the addressable memory space?) but then we should
likely get range errors.

Of course, doing this properly might also mean less work for moving to
arbitrary-size integers eventually (probably using the Lisp_Int1 tag
when the 28-bit range does not suffice), though that one will likely
need a lot of converting `eq' -> `eql' in the Lisp code base.

But first we should get wide ints behave sensibly when their range
exceeds the expected target range.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]