[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:1.9.2.17) 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
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9079#26>.
- size_t vs EMACS_INT, Eli Zaretskii, 2011/07/15
- Re: size_t vs EMACS_INT,
Paul Eggert <=
- Re: size_t vs EMACS_INT, Eli Zaretskii, 2011/07/15
- Re: size_t vs EMACS_INT, Paul Eggert, 2011/07/15
- Re: size_t vs EMACS_INT, Eli Zaretskii, 2011/07/15
- Re: size_t vs EMACS_INT, Paul Eggert, 2011/07/15
- Re: size_t vs EMACS_INT, Eli Zaretskii, 2011/07/16
- Re: size_t vs EMACS_INT, Paul Eggert, 2011/07/16