[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 09:38:29 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 |
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.