From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: oops? read/write vs type of length parameter Date: Wed, 13 Apr 2011 01:15:01 -0700 Organization: UCLA Computer Science Department Message-ID: <4DA55B85.5090305@cs.ucla.edu> References: <87wrj1jhfc.fsf@rho.meyering.net> <87hba5yq0p.fsf@uwakimon.sk.tsukuba.ac.jp> <834o64sxd7.fsf@gnu.org> <4DA3A7F8.1020503@cs.ucla.edu> <83k4f0qijz.fsf@gnu.org> <4DA3DDCD.10700@cs.ucla.edu> <4DA40AFE.8050406@cs.ucla.edu> <4DA47581.9010509@cs.ucla.edu> <4DA53148.5000903@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1302682530 24044 80.91.229.12 (13 Apr 2011 08:15:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 13 Apr 2011 08:15:30 +0000 (UTC) Cc: jim@meyering.net, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 13 10:15:20 2011 Return-path: Envelope-to: ged-emacs-devel@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 1Q9vEO-0003jD-J5 for ged-emacs-devel@m.gmane.org; Wed, 13 Apr 2011 10:15:20 +0200 Original-Received: from localhost ([::1]:39255 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9vEO-00011G-17 for ged-emacs-devel@m.gmane.org; Wed, 13 Apr 2011 04:15:20 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9vEG-00010y-JA for emacs-devel@gnu.org; Wed, 13 Apr 2011 04:15:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9vEC-0008Nl-LD for emacs-devel@gnu.org; Wed, 13 Apr 2011 04:15:12 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:35519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9vE7-0008K9-Oj; Wed, 13 Apr 2011 04:15:03 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 8BE0A39E80F5; Wed, 13 Apr 2011 01:15: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 OsLf3kfVUECS; Wed, 13 Apr 2011 01:15:02 -0700 (PDT) Original-Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 1A85D39E80B1; Wed, 13 Apr 2011 01:15:02 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 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:138457 Archived-At: On 04/12/2011 11:37 PM, Eli Zaretskii wrote: > The current code handles this situation (by looping for what's left > to write), while your suggested code will treat that as a fatal error. No, the suggested code also loops for what's left to write. Perhaps you misread the code? (or am I misunderstanding your comment?) > Emacs cannot have buffers (or any other streams of bytes) that are > larger than SSIZE_MAX, because a small number of bits is reserved for > the Lisp tags. That kind of argument violates abstraction boundaries: sysdep.c is supposed to be about system things, and it's not supposed to rely on assumptions about Emacs Lisp internals. There may be a few violations of these abstraction boundaries now, but let's not make this worse. For example, it would be a fairly small change to make Emacs buildable on a machine with 32-bit pointers and 64-bit EMACS_INT. And this would have real advantages: on 32-bit hosts it would remove the arbitrary (and really annoying :-) 256 MiB limit on editable files. But it would mean that Emacs *could* have buffers larger than SSIZE_MAX. emacs_write should not stand in the way of plausible improvements such as this one. > It was also about a mistaken > call to emacs_write with a negative value in the last argument... > > That danger still exists with your proposed version of emacs_write, No it doesn't, because I've carefully audited all the Emacs code (which is how I found all those *other* bugs :-). With the proposed change, emacs_write is never called with a negative argument.