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

[Stefan Monnier]

Let me first say that I'm not terribly excited by this idea of
a 32+64bit compilation option: ignoring the fact that many 32bit OSes do
not provide a full 4GB virtual address space to the Emacs process, such
a change can only bump the limit from 512MB to less than 4GB.
Of course, it will satisfy some particular uses, but it won't remove the
fundamental problem.

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

Makes me wonder: why use EMACS_INTPTR rather than intptr_t?

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

The old code is correct all right: void* can hold a 32bit value, and
XHASH takes a 32bit value and returns a 32bit value (it's a perfect hash
function, in a sense).  OTOH XPNTR takes a 32bit value and returns
a 29bit value, so there's loss of information, whereas XHASH was
specially designed to return an integer value without any loss of
information.  And indeed, if the user passes the right Lisp integer at
the right place, the above new test may return true even though an
integer should clearly not be treated as equal to a symbol.

I.e. XPNTR should never be used on an INTEGERP value.  For other values
it's OK since they're all boxed as pointers, and the 29bit returned by
XPNTR has only thrown away redundant info (tho this redundancy may be
difficult to recover).

So it might be OK to replace XHASH with XPNTR, but only if you catch the
INTEGERP case beforehand.

> @@ -2144,7 +2144,7 @@
>         We used to use 0 here, but that leads to accidental sharing in
>         purecopy's hash-consing, so we use a (hopefully) unique integer
>         instead.  */
> -    docstring = make_number (XHASH (function));
> +    docstring = make_number (XPNTR (function));
>    return Ffset (function,
>               Fpurecopy (list5 (Qautoload, file, docstring,
>                                 interactive, type)));

You lost me here.  make_number doesn't take a pointer as argument.
Even tho it's called "hash" it should not lose any information, so XHASH
is the right thing to use here, AFAICT.

>    if (wimage)
>      {
> -      /* The EMACS_INT cast avoids a warning. */
> +      EMACS_INTPTR ii = i;
> +      gpointer gi = (gpointer) ii;
> +

I saw various places where you do something similar.  Is there
a particular reason why you use an intermediate var rather than use the
more concise "(gpointer) (EMACS_INTPTR) i"?


        Stefan