Re: size_t vs EMACS_INT

[Paul Eggert]

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