From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts Date: Fri, 29 Apr 2011 11:49:26 +0300 Message-ID: <83mxj97889.fsf@gnu.org> References: <4DBA71FB.5090900@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1304066978 19335 80.91.229.12 (29 Apr 2011 08:49:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 29 Apr 2011 08:49:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 29 10:49:34 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 1QFjOH-0004kA-Kc for ged-emacs-devel@m.gmane.org; Fri, 29 Apr 2011 10:49:33 +0200 Original-Received: from localhost ([::1]:54125 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFjOG-0000ME-T7 for ged-emacs-devel@m.gmane.org; Fri, 29 Apr 2011 04:49:32 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:60896) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFjOE-0000Lx-U2 for emacs-devel@gnu.org; Fri, 29 Apr 2011 04:49:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QFjOD-0001Jc-SJ for emacs-devel@gnu.org; Fri, 29 Apr 2011 04:49:30 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:40005) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFjOD-0001JL-Gz for emacs-devel@gnu.org; Fri, 29 Apr 2011 04:49:29 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LKE00400OHUBI00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 29 Apr 2011 11:49:27 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.124.171.216]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LKE004WGOIDA610@a-mtaout20.012.net.il>; Fri, 29 Apr 2011 11:49:26 +0300 (IDT) In-reply-to: <4DBA71FB.5090900@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.166 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:138888 Archived-At: > Date: Fri, 29 Apr 2011 01:08:27 -0700 > From: Paul Eggert > > Currently, the Emacs C-language code assumes that EMACS_INT and > pointers have the same width. This is true of current ports, but I'd > like to create a 32-bit port with 64-bit EMACS_INT, so that Emacs is > not arbitrarily restricted by its small integer range when editing > large files on 32-bit hosts. I'll call this a "32+64-bit port". Thank you for doing this. > The main change in this patch is to introduce the types EMACS_INTPTR > and EMACS_UINTPTR, which are like EMACS_INT and EMACS_UINT but are > defined to be just wide enough to represent a pointer. Maybe it's just me, but I'm slightly worried by these names: they sound as if they represent pointers, but in fact you use them as integer types to avoid compiler warnings and casts (even though you used pointer types such as intptr_t to define these macros). How about EMACS_LONG and EMACS_ULONG instead? Or maybe EMACS_LONGEST and EMACS_ULONGEST, or just LONGEST and ULONGEST? IOW, wouldn't it be better to have names that tell explicitly they are integers, not pointers? Also, wrt changes such as this one: > - 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. > Step 2 will change EMACS_INT to be 64 bits on 32+64-bit ports. > That is a bigger deal, and I'll send a later email about it. When you do that, please don't hardwire "long long" for the 32+64-bit builds. That type is not standard enough in C90; in particular the MSVC compiler we still support for Windows doesn't have it, but it does have compatible __int64 and __uint64 types. Using an Emacs-specific typedef or macro will help adapting the MSVC Windows build (and probably others that don't use GCC) to this new configuration.