Re: size_t vs EMACS_INT

[Paul Eggert]

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
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9079#26>.