From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts Date: Mon, 02 May 2011 11:46:42 -0300 Message-ID: References: <4DBA71FB.5090900@cs.ucla.edu> <83mxj97889.fsf@gnu.org> <4DBA7F87.5040609@cs.ucla.edu> <4DBB67E2.1040202@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1304347617 21589 80.91.229.12 (2 May 2011 14:46:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 May 2011 14:46:57 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 02 16:46:52 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QGuOh-0001WL-Op for ged-emacs-devel@m.gmane.org; Mon, 02 May 2011 16:46:51 +0200 Original-Received: from localhost ([::1]:37647 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QGuOh-0000Np-0a for ged-emacs-devel@m.gmane.org; Mon, 02 May 2011 10:46:51 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:48588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QGuOd-0000NX-JL for emacs-devel@gnu.org; Mon, 02 May 2011 10:46:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QGuOc-0004n3-BH for emacs-devel@gnu.org; Mon, 02 May 2011 10:46:47 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:55712) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QGuOc-0004ms-7n for emacs-devel@gnu.org; Mon, 02 May 2011 10:46:46 -0400 Original-Received: from 121-249-126-200.fibertel.com.ar ([200.126.249.121]:51740 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QGuOb-0002sN-Hf; Mon, 02 May 2011 10:46:45 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 082A166119; Mon, 2 May 2011 11:46:43 -0300 (ART) In-Reply-To: <4DBB67E2.1040202@cs.ucla.edu> (Paul Eggert's message of "Fri, 29 Apr 2011 18:37:38 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:138958 Archived-At: >> 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