From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: 64-bit lossage Date: Thu, 01 Aug 2002 13:19:44 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200207310555.g6V5t4X16532@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1028222379 19031 127.0.0.1 (1 Aug 2002 17:19:39 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 1 Aug 2002 17:19:39 +0000 (UTC) Cc: d.love@dl.ac.uk, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17aJbt-0004wq-00 for ; Thu, 01 Aug 2002 19:19:37 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17aJug-00048i-00 for ; Thu, 01 Aug 2002 19:39:02 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17aJcJ-00052x-00; Thu, 01 Aug 2002 13:20:03 -0400 Original-Received: from 208-59-178-90.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([208.59.178.90] helo=raeburn.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17aJc3-0004ze-00; Thu, 01 Aug 2002 13:19:47 -0400 Original-Received: from kal-el.raeburn.org ([2002:d03b:b25a:1:201:2ff:fe23:e26d]) by raeburn.org (8.11.3/8.11.3) with ESMTP id g71HJjf13310; Thu, 1 Aug 2002 13:19:45 -0400 (EDT) Original-Received: from raeburn by kal-el.raeburn.org with local (Exim 3.35 #1 (Debian)) id 17aJc0-0005qz-00; Thu, 01 Aug 2002 13:19:44 -0400 Original-To: rms@gnu.org In-Reply-To: <200207310555.g6V5t4X16532@aztec.santafe.edu> (Richard Stallman's message of "Tue, 30 Jul 2002 23:55:04 -0600 (MDT)") Original-Lines: 32 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1.50 (i686-pc-linux-gnu) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:6230 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6230 Richard Stallman writes: > Conversions between pointers and integers in Emacs all seem to assume > that EMACS_INT is the same size as a pointer, and that would need > fixing, mostly outside of lisp.h. Probably an Emacs version of C99's > intptr_t would do the trick. > > What is the case you'd like it to handle > where the two sizes are different? Wider integer support on a 32-bit platform, so larger files can be supported, buffer offsets can still be described, etc. They would still be bounded by the address space, of course, so it could only gain maybe a factor of 4 or 8 at most, unless we work up a way to edit huge files we can't copy into memory all at once. It would also allow handling of true 32-bit values (or even somewhat larger) for file sizes, uids, etc. Many of the cases where conversions are done are probably safe already, compiler warnings aside, but I suspect sign-/zero-extension mistakes might be made in a few cases, if there aren't any configurations of this sort that have been made to work before. But after looking at it a little, I think doubling the size of a Lisp_Object is probably not worth it. There are other possible approaches to getting bigger integer values supported in Emacs. I'm not really inclined to do that much work rewriting the existing lisp system, though, even if it did look like a good idea, since switching to Guile objects would have a similar effect. Ken