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: Buffer size limitation in insdel.c Date: Sat, 25 Sep 2010 15:55:26 +0200 Message-ID: <831v8irkq9.fsf@gnu.org> References: <834odivv7v.fsf@gnu.org> <83r5gkvqpf.fsf@gnu.org> <834odftdvy.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1285422947 13700 80.91.229.12 (25 Sep 2010 13:55:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 25 Sep 2010 13:55:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lars Magne Ingebrigtsen , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 25 15:55:46 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OzVE8-0005J8-A3 for ged-emacs-devel@m.gmane.org; Sat, 25 Sep 2010 15:55:44 +0200 Original-Received: from localhost ([127.0.0.1]:51321 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OzVE7-00041l-MP for ged-emacs-devel@m.gmane.org; Sat, 25 Sep 2010 09:55:43 -0400 Original-Received: from [140.186.70.92] (port=53197 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OzVDs-0003y8-Le for emacs-devel@gnu.org; Sat, 25 Sep 2010 09:55:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OzVDm-0000f7-KP for emacs-devel@gnu.org; Sat, 25 Sep 2010 09:55:28 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:37617) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OzVDm-0000ex-C8 for emacs-devel@gnu.org; Sat, 25 Sep 2010 09:55:22 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0L9B0010022XWQ00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Sat, 25 Sep 2010 15:55:20 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.127.203.3]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L9B001A82O7XM00@a-mtaout21.012.net.il>; Sat, 25 Sep 2010 15:55:20 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:130843 Archived-At: > From: Lars Magne Ingebrigtsen > Date: Fri, 24 Sep 2010 16:38:16 +0200 > > Eli Zaretskii writes: > > > The reason for this code is that many places use an int to hold buffer > > positions. All these places are bugs; they should use EMACS_INT > > instead. This code hides those bugs. > > After we've done the initial EMACS_INT/int sweep (shouldn't take more > than a week, right? :-), we can remove the limitation, try to load a big > file, and see what happens... I've now finished reviewing all the sources that Lars didn't handle and fixing any uses of int for buffer and string positions and sizes. The only places where I left such code that uses ints unchanged is when the string or buffer is known in advance to be short. A typical example is a string that is a name of a symbol, or a message shown in the echo area. I also left alone code that processes the doc strings. Files I didn't review are: w32*.c files (since the 32-bit Windows build obviously is not affected), and xselect.c (if it's possible to have X selections larger than 2GB, then someone who knows more than I do about this should take a look). Whether to remove the above limitation should now be a purely managerial decision. Stefan and Chong, your call. P.S. Note that I went through the sources manually, not with GCC warnings that Lars used. So I only fixed code that used ints to refer to buffer and string positions, not every place where an EMACS_INT is placed into an int. And that's in addition to any places I could have missed, of course.