From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts
Date: Mon, 02 May 2011 11:46:42 -0300 [thread overview]
Message-ID: <jwv4o5dfa7r.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <4DBB67E2.1040202@cs.ucla.edu> (Paul Eggert's message of "Fri, 29 Apr 2011 18:37:38 -0700")
>> 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
next prev parent reply other threads:[~2011-05-02 14:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-29 8:08 bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts Paul Eggert
2011-04-29 8:49 ` Eli Zaretskii
2011-04-29 9:06 ` Paul Eggert
2011-04-29 9:17 ` Eli Zaretskii
2011-04-29 16:04 ` Stefan Monnier
2011-04-29 17:10 ` Eli Zaretskii
2011-04-29 17:32 ` Lars Magne Ingebrigtsen
2011-04-29 17:45 ` Paul Eggert
2011-04-29 18:50 ` David De La Harpe Golden
2011-04-30 5:00 ` Stephen J. Turnbull
2011-04-30 1:37 ` Paul Eggert
2011-05-02 14:46 ` Stefan Monnier [this message]
2011-05-02 16:09 ` Paul Eggert
2011-05-02 18:12 ` Stefan Monnier
2011-05-02 19:23 ` Paul Eggert
2011-05-02 19:49 ` Stefan Monnier
2011-04-30 6:54 ` Paul Eggert
2011-04-30 7:30 ` Eli Zaretskii
2011-04-29 8:56 ` support " Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv4o5dfa7r.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eggert@cs.ucla.edu \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.