[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 00:15:04 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110516 Thunderbird/3.1.10

On 07/14/11 23:42, Eli Zaretskii wrote:

>   -static size_t bidi_cache_size = 0;
>   +static EMACS_INT bidi_cache_size = 0;
> is not a good idea.  I understand the motivation for using a signed
> type, but EMACS_INT isn't just a signed type, it's 3 bits narrower
> than size_t, at least on some platforms.

But the code in question doesn't use tag bits.  So there's no issue
about EMACS_INT being 2 or 3 bits narrower than the machine integer.
On all practical Emacs porting targets, EMACS_INT is at least as wide
as size_t, and the above change does not impose any new limits.

> By contrast, the bidi cache should be able to support the longest
> Lisp string/buffer, and for that it needs to have
> MOST_POSITIVE_FIXNUM _elements_, not bytes

Not exactly.  Although the longest Lisp string/buffer indeed cannot
exceed MOST_POSITIVE_FIXNUM elements, there are two other constraints:
it cannot exceed SIZE_MAX elements, and it cannot exceed PTRDIFF_MAX
elements.  All three constraints are necessary to prevent various
disasters in the underlying C code.  And the Emacs allocators enforce
these constraints.  For more details, please see the definitions of
STRING_BYTES_BOUND in lisp.h, and of BUF_BYTES_MAX in buffer.h.

Therefore, EMACS_INT, ptrdiff_t, and size_t are all wide enough
to count a buffer size or string length.

We prefer signed types, so we avoid size_t.

We should also prefer ptrdiff_t to EMACS_INT for such purposes.  These
two are normally the same type, except on 32-bit hosts configured
--with-wide-int where the former is 32 bits and the latter is 64 bits.
In that case, ptrdiff_t is preferable because it is more efficient.
That is why the subsequent patch proposed in
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9079#26> changes
bidi_cache_size from EMACS_INT to ptrdiff_t.

A goodly amount of existing Emacs code uses EMACS_INT where ptrdiff_t
would do.  I have several fixes for this, which I plan to submit at
some point.  But in the meantime, new code should prefer ptrdiff_t to
EMACS_INT where either type would do.

> So the net effect of the above change is to limit the cache to 1/8th
> of the maximum size it could have before the change.

I hope the above comments explain why the change does not place any
limits on the cache size that were not already there.

I'll follow up further at the bug report

reply via email to

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