[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: size_t vs EMACS_INT

From: Eli Zaretskii
Subject: Re: size_t vs EMACS_INT
Date: Fri, 15 Jul 2011 11:10:57 +0300

> 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

> 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.

reply via email to

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