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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 29 Apr 2011 01:08:27 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> Currently, the Emacs C-language code assumes that EMACS_INT and
> pointers have the same width.  This is true of current ports, but I'd
> like to create a 32-bit port with 64-bit EMACS_INT, so that Emacs is
> not arbitrarily restricted by its small integer range when editing
> large files on 32-bit hosts.  I'll call this a "32+64-bit port".

Thank you for doing this.

> The main change in this patch is to introduce the types EMACS_INTPTR
> and EMACS_UINTPTR, which are like EMACS_INT and EMACS_UINT but are
> defined to be just wide enough to represent a pointer.

Maybe it's just me, but I'm slightly worried by these names: they
sound as if they represent pointers, but in fact 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).  How
about EMACS_LONG and EMACS_ULONG instead?  Or maybe EMACS_LONGEST and
EMACS_ULONGEST, or just LONGEST and ULONGEST?  IOW, wouldn't it be
better to have names that tell explicitly they are integers, not
pointers?

Also, wrt changes such as this one:

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

> 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.  Using an
Emacs-specific typedef or macro will help adapting the MSVC Windows
build (and probably others that don't use GCC) to this new
configuration.