Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts

[Paul Eggert <eggert@cs.ucla.edu>]

On 04/29/11 01:49, Eli Zaretskii wrote:

> Maybe it's just me, but I'm slightly worried by these names: they
> sound as if they represent pointers,

Yes, that's exactly what they're for.  EMACS_INTPTR is the Emacs
analog of the standard C type intptr_t, which is a integer type that
is wide enough to hold a pointer, i.e., one can convert from void * to
intptr_t and back again without losing information.

The name "intptr" may be a bit confusing to a reader who doesn't
know C99, but once you're used to the standard meaning, any other name
would sound weird.

> you use them as integer types to avoid compiler warnings and casts
> (even though you used pointer types such as intptr_t to define these macros).

No, intptr_t is an integer type; it's not a pointer type.

> How about EMACS_LONG and EMACS_ULONG instead?

That wouldn't be good, because in a typical 32+64-bit host, EMACS_LONG
would be narrower than EMACS_INT.

>> > -  if (data != NULL && data == (void*) XHASH (QCdbus_session_bus))
>> > +  if (data != NULL && data == (void *) XPNTR (QCdbus_session_bus))
> I wonder if we aren't obfuscating the code a bit too much, since XHASH
> says something about its argument, while XPNTR is too general to
> convey any such useful information.  Unless, that is, you are saying
> that the use of XHASH here was bogus to begin with, and all that was
> needed was a pointer.

Yes, that's what it's saying.  void * is supposed to hold only a
pointer: in general it can't hold a pointer plus a tag.  So the
old code wasn't correct.  (It was good enough for the current ports,
but not good enough for a 32+64-bit port.)

>> > Step 2 will change EMACS_INT to be 64 bits on 32+64-bit ports.
>> > That is a bigger deal, and I'll send a later email about it.
> When you do that, please don't hardwire "long long" for the 32+64-bit
> builds.  That type is not standard enough in C90; in particular the
> MSVC compiler we still support for Windows doesn't have it, but it
> does have compatible __int64 and __uint64 types.

Thanks, I hadn't thought of that.  Before I got your email I already
sent out a simple patch
<http://lists.gnu.org/archive/html/emacs-devel/2011-04/msg00908.html>
that did not use __int64 (so it continued to use 32-bit int on
Windows).  I will look into extending that patch, so that it also works with
__int64.