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: Tue, 12 Apr 2011 08:53:37 -0700 Organization: UCLA Computer Science Department Message-ID: <4DA47581.9010509@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> 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 1302623641 13976 80.91.229.12 (12 Apr 2011 15:54:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 12 Apr 2011 15:54:01 +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 Tue Apr 12 17:53:55 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 1Q9fud-00009O-5c for ged-emacs-devel@m.gmane.org; Tue, 12 Apr 2011 17:53:55 +0200 Original-Received: from localhost ([::1]:47424 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9fuc-0007Lr-Pt for ged-emacs-devel@m.gmane.org; Tue, 12 Apr 2011 11:53:54 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54819) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9fuZ-0007LV-Ez for emacs-devel@gnu.org; Tue, 12 Apr 2011 11:53:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9fuU-00006V-M5 for emacs-devel@gnu.org; Tue, 12 Apr 2011 11:53:51 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:48692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9fuP-00005q-AW; Tue, 12 Apr 2011 11:53:41 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id C8FF539E80DB; Tue, 12 Apr 2011 08:53:39 -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 p+QDVVVVAux2; Tue, 12 Apr 2011 08:53:38 -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 7666C39E8082; Tue, 12 Apr 2011 08:53:38 -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:138441 Archived-At: On 04/12/2011 02:41 AM, Eli Zaretskii wrote: >> Date: Tue, 12 Apr 2011 01:19:10 -0700 >> From: Paul Eggert >> CC: emacs-devel@gnu.org, Jim Meyering >> >> I added a runtime check for this, which I don't think >> will ever fail, but I've been surprised in the past. > > If it ever fails, aborting is too harsh, I think. The original code > was well defended against that possibility, see write-region. It > would signal an IO error. If the code is well-defended against passing negative sizes, then we can remove the checks entirely; they're not needed. They were meant only as a stopgap in case the callers were buggy. (Also please see below.) >> With that check in place we might as well use size_t for the size, > > Which will cause annoying compiler warnings, at least with some > optional switches. Any compiler that will warn about conversions to size_t will warn about hundreds of other places in Emacs. These warnings are more trouble than they're worth, and we shouldn't worry about them. >> with the goal of removing the runtime checks once we have >> carefully checked that they aren't needed. > > Which will never happen, so these aborts will stay in the code > forever. I can do it, in the next day or two. It shouldn't be a problem. I'm sorry if there are hurt feelings about this, but size_t is clearly the better choice for buffer sizes; it's the universal standard in the C API. ssize_t is never used for that. And this is the sysdep.c module after all.