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

[Stefan Monnier]

>> why use EMACS_INTPTR rather than intptr_t?
> An excess of caution. :-)  I'll change it to intptr_t.

Thanks; having to use EMACS_INT rather than `int' is painful enough
already.

> OK, thanks.  Since busses are always symbols, I'll change that to:
>   if (SYMBOLP (QCdbus_session_bus) && XSYMBOL (QCdbus_session_bus) == data)

Sounds good.

> With this change, there shouldn't be a need to cast to void *, right?

Possibly.  I'd ask Paul for these kinds of details ;-)

> (A cast would be needed if Emacs were intended to be compilable by
> a C++ compiler, but I assume that's not a goal.)

It's not a goal, indeed, tho IIRC someone recently installed changes to
make it possible to compile with a C++ compiler (or was it for ObjC?
can't remember).

>>> > -    docstring = make_number (XHASH (function));
>>> > +    docstring = make_number (XPNTR (function));
>> 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.

> But 'function' is a Lisp_Object, so it's already a tagged pointer
> that's possibly shifted.  make_number will tag it and possibly shift
> it again, which can lose info about the pointer; and this means
> purecopy's hash-consing could mess up.

> In other words, the XHASH can cause a bug even on an ordinary 32-bit host.

> XPNTR can't lose any information about the actual pointer, since
> 'function' is guaranteed to be a symbol here.  That's why this code is
> different from the dbus code mentioned above.

Yes and no: that's true for some platforms, but in most platforms
(including Windows, Mac OS X, and GNU/Linux), the 3bit tag is in the
LSB, so the difference between XHASH and XPNTR is not the shifting
(neither does shifting in this case) but in that XPNTR masks the 3 LSB.

Now, in practice, the difference is negligible since as you point out
(and I had forgotten), those 3bits are constant since `function' is
always a symbol.  So the data "thrown away" by XPNTR doesn't contain any
significant information for hashing purposes.
E.g. sxhash uses "XPNTR (obj) >> 3" where the >>3 is there to compensate
for make_number's dropping the 3 MSB.

So I guess it's OK to drop XHASH, but please use XSYMBOL rather
than XPNTR.

>>> > -      /* The EMACS_INT cast avoids a warning. */
>>> > +      EMACS_INTPTR ii = i;
>>> > +      gpointer gi = (gpointer) ii;
>> Is there a particular reason why you use an intermediate var rather
>> than use the more concise "(gpointer) (EMACS_INTPTR) i"?
> To avoid a cast.

I'm not sure what is the formal definition of "cast" in C, but at least
from my point of view, your code performs just the same kind of coercion
as a cast.

> If you prefer conciseness to avoiding these casts, I can easily change
> these to the more-concise form.

I do prefer the more concise form, and paradoxically part of the reason
is because it is uses a explicit coercion rather than an implicit one.


        Stefan