From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#8794: cons_to_long fixes; making 64-bit EMACS_INT the default Date: Fri, 03 Jun 2011 10:53:55 -0700 Organization: UCLA Computer Science Department Message-ID: <4DE91FB3.80601@cs.ucla.edu> References: <4DE89EB8.9020202@cs.ucla.edu> <83oc2fdw59.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1307123804 18103 80.91.229.12 (3 Jun 2011 17:56:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 3 Jun 2011 17:56:44 +0000 (UTC) Cc: 8794@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 03 19:56:39 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1QSYbu-0006Su-Ln for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Jun 2011 19:56:38 +0200 Original-Received: from localhost ([::1]:45881 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSYbt-0004o5-FP for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Jun 2011 13:56:37 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:55543) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSYaP-0004Pj-Pl for bug-gnu-emacs@gnu.org; Fri, 03 Jun 2011 13:55:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSYaN-0007y7-1s for bug-gnu-emacs@gnu.org; Fri, 03 Jun 2011 13:55:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44439) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSYaM-0007y1-SV for bug-gnu-emacs@gnu.org; Fri, 03 Jun 2011 13:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QSYaM-0000hi-17; Fri, 03 Jun 2011 13:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Jun 2011 17:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8794 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8794-submit@debbugs.gnu.org id=B8794.13071236512643 (code B ref 8794); Fri, 03 Jun 2011 17:55:01 +0000 Original-Received: (at 8794) by debbugs.gnu.org; 3 Jun 2011 17:54:11 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QSYZW-0000ga-NI for submit@debbugs.gnu.org; Fri, 03 Jun 2011 13:54:11 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QSYZU-0000gK-4T for 8794@debbugs.gnu.org; Fri, 03 Jun 2011 13:54:09 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 6F6C139E80F8; Fri, 3 Jun 2011 10:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fVnGOZ6chlc; Fri, 3 Jun 2011 10:54:01 -0700 (PDT) Original-Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 6A56239E80FF; Fri, 3 Jun 2011 10:54:01 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10 In-Reply-To: <83oc2fdw59.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 03 Jun 2011 13:55:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:46924 Archived-At: >> I wrote some code to fix them systematically, and found that >> it was simpler and more reliable if I could assume that EMACS_INT >> was 64-bit even on 32-bit hosts. > > I don't think we agreed to make that the only configurations on 32-bit > machines. Sorry, I should have explained more clearly. If there is a system integer type (such as ino_t or time_t) that is 64 bits, it's cleaner if EMACS_INT is also 64 bits. And in practice this requirement is not a problem, as any 32-bit host where some standard system types are 64 bits supports 64-bit integers quite well. On an old-fashioned host where all the system types are 32 bits, EMACS_INT can still be 32 bits. > Can 32-bit hosts really support buffers and strings larger than 2GB, > even if EMACS_INT is a 64-bit type? Yes, absolutely. For example: #include #include #include int main (void) { int big = 536870913; int *p = malloc (big * sizeof *p); if (!p) return 1; memset (p, 0xef, big * sizeof *p); printf ("%x %x\n", p[0], p[big - 1]); return 0; } On my RHEL 5.6 host, built as a 32-bit executable, this outputs: $ gcc -m32 t.c $ ./a.out efefefef efefefef even though the array's size does not fit in 'int' or 'long'. The same behavior can be observed on pure 32-bit systems; it's quite common and has been for years. > I thought the largest object on a > 32-but machine cannot exceed 2GB due to pointer arithmetics, No, but as shown above one can often allocate objects larger than 2 GiB on such machines. Perhaps you're thinking of pointer subtraction? That often stops working on arrays larger than 2 GiB. But this is easy to program around. And anyway, even if we assume buffers and strings are all smaller than 2 GiB, an EMACS_INT wider than 32 bits is still needed for large buffers and strings, due to the tag bits. >> Emacs cannot visit files that are larger than the maximum Emacs buffer >> -size, which is around 512 megabytes on 32-bit machines >> +size, which is around 512 MiB on 32-bit machines and 2 EiB on 64-bit machines >> (@pxref{Buffers}). If you try, Emacs will display an error message >> saying that the maximum buffer size has been exceeded. > > This seems to contradict what you said about buffers, doesn't it? Yes, thanks, I messed that up; I'll fix that part of the documentation. >> + if (NATNUMP (top) && XFASTINT (top) <= UINTMAX_MAX >> 16 && NATNUMP (bo> > The *_MAX macros need limits.h, but I don't see it being included by > data.c. Did I miss something? Those are OK because lisp.h includes inttypes.h. INTMAX_MAX and UINTMAX_MAX are defined by inttypes.h (actually, stdint.h, but inttypes.h includes stdint.h). Like you, I would have put all the _MIN and _MAX macros into limits.h, but I wasn't part of that design decision.