Re: size_t vs EMACS_INT

[Eli Zaretskii]

> Date: Fri, 15 Jul 2011 00:15:04 -0700
> From: Paul Eggert <address@hidden>
> CC: address@hidden
> 
> 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.

Today, no issue.  But some day the representation of EMACS_INT might
be changed, and when that happens, it would be good to have all the
variables that are related to that type be clearly marked in the
sources.  Otherwise, we will have to wade through all the places
trying to understand which variable is really EMACS_INT and which is
size_t or ptrdiff_t.  Having done that recently, when I worked on
editing buffers larger than 2GB on 64-bit hosts, I can tell you it's
no fun.

> We prefer signed types, so we avoid size_t.

Then let's use ssize_t.  I submit that EMACS_INT should not be used
for anything that is not directly related to buffer or string
positions.

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

Practically speaking, with today's implementation of EMACS_INT, it
doesn't.  But that wasn't my point.  My point was that _conceptually_,
EMACS_INT is limited to MOST_POSITIVE_FIXNUM, which is way smaller
than SIZE_T_MAX on many platforms.  We should not IMO let assumptions
based on implementation details creep into the code, except where
strictly necessary.  This isn't a case of such a necessity, IMO.