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: Fri, 29 Apr 2011 13:04:07 -0300 Message-ID: References: <4DBA71FB.5090900@cs.ucla.edu> <83mxj97889.fsf@gnu.org> <4DBA7F87.5040609@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1304093060 11907 80.91.229.12 (29 Apr 2011 16:04:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 29 Apr 2011 16:04:20 +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 Fri Apr 29 18:04:15 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 1QFqAw-0006Iv-Tz for ged-emacs-devel@m.gmane.org; Fri, 29 Apr 2011 18:04:15 +0200 Original-Received: from localhost ([::1]:51506 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFqAw-00043Z-Fe for ged-emacs-devel@m.gmane.org; Fri, 29 Apr 2011 12:04:14 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:39016) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFqAu-00043U-Aq for emacs-devel@gnu.org; Fri, 29 Apr 2011 12:04:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QFqAt-0005Hh-C3 for emacs-devel@gnu.org; Fri, 29 Apr 2011 12:04:12 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:52219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFqAt-0005Hd-9B for emacs-devel@gnu.org; Fri, 29 Apr 2011 12:04:11 -0400 Original-Received: from 121-249-126-200.fibertel.com.ar ([200.126.249.121]:22787 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QFqAs-0007Xq-Rs; Fri, 29 Apr 2011 12:04:11 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 3DC08660D4; Fri, 29 Apr 2011 13:04:07 -0300 (ART) In-Reply-To: <4DBA7F87.5040609@cs.ucla.edu> (Paul Eggert's message of "Fri, 29 Apr 2011 02:06:15 -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:138900 Archived-At: 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