[Top][All Lists]

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

Re: size_t vs EMACS_INT

From: Paul Eggert
Subject: Re: size_t vs EMACS_INT
Date: Fri, 15 Jul 2011 14:52:56 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110516 Thunderbird/3.1.10

On 07/15/11 10:14, Eli Zaretskii wrote:

> ptrdiff_t should do, right?  If so, let's use that.

Yes, thanks, that sounds like the best way to go.

>> > A lot of Emacs code assumes that MOST_POSITIVE_FIXNUM is much
>> > less than TYPE_MAXIMUM (EMACS_INT), and any change to that assumption
>> > would require a significant rewrite of the Emacs internals.
> Can you show examples of these assumptions?

The most central examples are the integer-extraction macros
in lisp.h, e.g., make_number, XINT.  Presumably these could be changed if
we take the big step of adopting some other implementation strategy
for Emacs integers, such that XINT (foo) could yield
TYPE_MAXIMUM (EMACS_INT).   But then we'd have to deal with examples
like the following, in Fforward_char:

    EMACS_INT new_point = PT + XINT (n);

This code is currently safe, since C code can always safely add
two Emacs fixnums, and the addition can't possibly overflow at the C level.
But if fixnums could equal TYPE_MAXIMUM (EMACS_INT),
this code would be unsafe and we would have to add a run-time
check for integer overflow.

There are many more examples like this, not all of them as
obvious as the above.  Here's one, from Frem:

  XSETINT (val, XINT (x) % XINT (y));

If XINT (x) could equal TYPE_MINIMUM (EMACS_INT), then this
would dump core on an x86 when XINT (y) == -1, because
INT_MIN % -1 dumps core on the x86 (the C standard allows this,
alas).  However, since XINT (x) cannot possibly equal
TYPE_MINIMUM (EMACS_INT), Emacs is currently safe from
this problem, and we don't need to insert a run-time check

reply via email to

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