[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
size_t vs EMACS_INT
From: |
Eli Zaretskii |
Subject: |
size_t vs EMACS_INT |
Date: |
Fri, 15 Jul 2011 09:42:41 +0300 |
Paul,
I think that part of your change in revision 105217 on the trunk, viz.
-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. 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. 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. So I think we will have
to use size_t here, and deal with whatever complications that causes
with GCC 4.6.x.
- size_t vs EMACS_INT,
Eli Zaretskii <=
- 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/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