From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#8794: cons_to_long fixes; making 64-bit EMACS_INT the default Date: Fri, 03 Jun 2011 13:52:50 +0300 Message-ID: <83oc2fdw59.fsf@gnu.org> References: <4DE89EB8.9020202@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1307098411 21779 80.91.229.12 (3 Jun 2011 10:53:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 3 Jun 2011 10:53:31 +0000 (UTC) Cc: 8794@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 03 12:53:22 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 1QSS0F-0001r5-HS for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Jun 2011 12:53:19 +0200 Original-Received: from localhost ([::1]:33836 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSS0E-0007ip-Oo for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Jun 2011 06:53:18 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:40056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSS00-0007ii-9e for bug-gnu-emacs@gnu.org; Fri, 03 Jun 2011 06:53:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSRzz-0000qj-2P for bug-gnu-emacs@gnu.org; Fri, 03 Jun 2011 06:53:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37262) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSRzy-0000qc-T7 for bug-gnu-emacs@gnu.org; Fri, 03 Jun 2011 06:53:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QSRzx-0006Ee-SB; Fri, 03 Jun 2011 06:53:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii 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 10:53: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.130709837023945 (code B ref 8794); Fri, 03 Jun 2011 10:53:01 +0000 Original-Received: (at 8794) by debbugs.gnu.org; 3 Jun 2011 10:52:50 +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 1QSRzl-0006E9-Bx for submit@debbugs.gnu.org; Fri, 03 Jun 2011 06:52:49 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QSRzi-0006Dw-17 for 8794@debbugs.gnu.org; Fri, 03 Jun 2011 06:52:47 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LM700900NJAWC00@a-mtaout20.012.net.il> for 8794@debbugs.gnu.org; Fri, 03 Jun 2011 13:52:39 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.229.223.140]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LM700925NJQGU30@a-mtaout20.012.net.il>; Fri, 03 Jun 2011 13:52:39 +0300 (IDT) In-reply-to: <4DE89EB8.9020202@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 03 Jun 2011 06:53:01 -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:46919 Archived-At: > Date: Fri, 03 Jun 2011 01:43:36 -0700 > From: Paul Eggert > > I found several problems in the Emacs code that converts > large C integers to Emacs conses-of-integers and back again. > 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. So here's a patch to do all that. I don't think we agreed to make that the only configurations on 32-bit machines. Did we? > +using that data type. For most machines, the maximum buffer size > +enforced by the data types is @math{2^61 - 2} bytes, or about 2 EiB. > +For some older machines, the maximum is @math{2^29 - 2} bytes, or > +about 512 MiB. Buffer sizes are also limited by the size of Emacs's > +virtual memory. Can 32-bit hosts really support buffers and strings larger than 2GB, even if EMACS_INT is a 64-bit type? I thought the largest object on a 32-but machine cannot exceed 2GB due to pointer arithmetics, which will wrap around after that. What am I missing? > 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? > === modified file 'src/data.c' > --- src/data.c 2011-05-31 14:57:53 +0000 > +++ src/data.c 2011-06-02 07:38:44 +0000 > @@ -23,8 +23,6 @@ > [...] > + else if (FLOATP (c)) > + { > + double d = XFLOAT_DATA (c); > + if (0 <= d > + && d < (max == UINTMAX_MAX ? (double) UINTMAX_MAX + 1 : max + 1)) > + { > + val = d; > + valid = 1; > + } > + } > + else if (CONSP (c)) > + { > + Lisp_Object top = XCAR (c); > + Lisp_Object bot = XCDR (c); > + if (CONSP (bot)) > + bot = XCAR (bot); > + if (NATNUMP (top) && XFASTINT (top) <= UINTMAX_MAX >> 16 && NATNUMP (bot)) > + { > + uintmax_t utop = XFASTINT (top); > + val = (utop << 16) | XFASTINT (bot); > + valid = 1; > + } > + } The *_MAX macros need limits.h, but I don't see it being included by data.c. Did I miss something? > +#define INTEGER_TO_CONS(i) \ > + (! FIXNUM_OVERFLOW_P (i) \ > + ? make_number (i) \ > + : ! ((FIXNUM_OVERFLOW_P (INTMAX_MIN >> 16) \ > + || FIXNUM_OVERFLOW_P (UINTMAX_MAX >> 16)) \ > + && FIXNUM_OVERFLOW_P ((i) >> 16)) \ > + ? Fcons (make_number ((i) >> 16), make_number ((i) & 0xffff)) \ > + : make_float (i)) Same here (this is from lisp.h). But since every C file includes lisp.h, it looks like we need to include limits.h in lisp.h.