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: Making --with-wide-int the default Date: Sun, 15 Nov 2015 23:02:01 +0200 Message-ID: <83d1vbc6ye.fsf@gnu.org> References: <83oag087gs.fsf@gnu.org> <83oafz70im.fsf@gnu.org> <5620AF43.4050401@cs.ucla.edu> <83k2qn6xfm.fsf@gnu.org> <5620B4FA.1000804@cs.ucla.edu> <83wptojs1r.fsf@gnu.org> <56444C66.8050506@gmx.at> <83r3jugx8g.fsf@gnu.org> <87io56nu0a.fsf@fencepost.gnu.org> <83lha1dl87.fsf@gnu.org> <871tbrmeu3.fsf@fencepost.gnu.org> <83pozbcaxi.fsf@gnu.org> <87pozbkn9r.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1447704887 19767 80.91.229.3 (16 Nov 2015 20:14:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Nov 2015 20:14:47 +0000 (UTC) Cc: rudalics@gmx.at, jwiegley@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 16 21:14:36 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZyQAS-0007MQ-Ta for ged-emacs-devel@m.gmane.org; Mon, 16 Nov 2015 21:14:25 +0100 Original-Received: from localhost ([::1]:48670 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyQAS-0002of-HI for ged-emacs-devel@m.gmane.org; Mon, 16 Nov 2015 15:14:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zy4RB-0000u2-0I for emacs-devel@gnu.org; Sun, 15 Nov 2015 16:02:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zy4R9-0002vm-SB for emacs-devel@gnu.org; Sun, 15 Nov 2015 16:02:12 -0500 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:53904) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zy4R5-0002ue-Uk; Sun, 15 Nov 2015 16:02:08 -0500 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NXV00300JMACT00@mtaout25.012.net.il>; Sun, 15 Nov 2015 22:59:36 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXV003C5JNC4800@mtaout25.012.net.il>; Sun, 15 Nov 2015 22:59:36 +0200 (IST) In-reply-to: <87pozbkn9r.fsf@fencepost.gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 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:194538 Archived-At: > From: David Kastrup > Cc: rms@gnu.org, rudalics@gmx.at, emacs-devel@gnu.org, jwiegley@gmail.com > Date: Sun, 15 Nov 2015 21:42:24 +0100 > > Eli Zaretskii writes: > > >> From: David Kastrup > >> Cc: rms@gnu.org, rudalics@gmx.at, emacs-devel@gnu.org, jwiegley@gmail.com > >> Date: Sun, 15 Nov 2015 17:01:40 +0100 > >> > >> Here is another data point: the code base seems woefully unprepared to > >> actually deal with the resulting ranges. > >> > >> Lisp integers are only converted with macros XINT and XFASTINT as far as > >> I can tell, and > >> > >> git grep XINT > >> > >> shows lots of assignments to variables of type int rather than > >> EMACS_INT. > > > > If these are real problems, they should have bitten us long ago, in > > the 64-bit builds, no? > > Why? Because an int is a 32-bit data type in 64-bit builds as well. So if we use XINT to assign to an int, and the value exceeds INT_MAX, the same problems will happen in both 64-bit builds and in 32-bit builds with wide ints. > They'll only trigger for cases that exceed a range of 32 bits, and > if those cases were other than rare, they'd have rendered the 32-bit > builds (which work with 30-bit precision) unusable. The same considerations apply to 64-bit builds. My point is that these issues, if they exist, are not unique to the 32-bit builds with wide ints, they are with us even without wide ints. > However, we never previously had the case that a number which looks fine > in Lisp does not transfer into C properly. Once again, if we assign an Emacs integer to a C int, we will have the same problems in 64-bit builds. Btw, it's not like we live dangerously there: these issues were extensively scrutinized several years ago, when we lifted the 2GB limit on buffers in 64-bit builds, and all the relevant code was carefully audited and fixed. It is, of course, possible that some new problems crept in, but the basis is sound, both for the 64-bit build and the 32-bit build with wide ints. Bottom line: I don't think there are new problems the 32-bit build with wide ints introduces that aren't with us in the 64-bit builds.