Re: size_t vs EMACS_INT

[Paul Eggert]

On 07/15/11 01:10, Eli Zaretskii wrote:
> EMACS_INT should not be used
> for anything that is not directly related to buffer or string
> positions.

No, EMACS_INT is for anything that is related to the Emacs
internal representation of integers.  It's not just buffer
and string positions.  There are lots of other uses: arithmetic,
calendars, time stamps, random numbers, image dimensions, etc.

> My point was that _conceptually_,
> EMACS_INT is limited to MOST_POSITIVE_FIXNUM

No, conceptually, EMACS_INT is limited to TYPE_MAXIMUM (EMACS_INT).
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.

And even if this assumption *were* to change, it would not affect
this particular case.  Here, the value in question cannot possibly
exceed PTRDIFF_MAX because it is counting something (a C array size)
that cannot exceed PTRDIFF_MAX without breaking things at the C
level.  The fact that the value also cannot exceed
MOST_POSITIVE_FIXNUM does not affect the fact that the value must
always fit into ptrdiff_t.

> let's use ssize_t

No, because POSIX allows ssize_t to be 32 bits on the same
platform where size_t is 64 bits.  The motivation for
ssize_t is "this is a signed integer type such that syscalls
like read() and write() will never return values larger than that".
This is why there is a SSIZE_MAX in POSIX, but no SSIZE_MIN;
in the POSIX context, there's no use for negative ssize_t values
other than -1.

On a host with 32-bit ssize_t and 64-bit size_t, one can read()
a terabyte buffer, but read() will never return more than 2 GiB at a
time.  That's not what we want here: here, the quantities
have nothing to do with I/O buffers, and they should not have
an arbitrary 32-bit limit on these 64-bit hosts.