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: Mon, 11 Apr 2011 22:06:21 -0700 Organization: UCLA Computer Science Department Message-ID: <4DA3DDCD.10700@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> 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 1302584809 15232 80.91.229.12 (12 Apr 2011 05:06:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 12 Apr 2011 05:06:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 12 07:06:45 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from [140.186.70.17] (helo=lists.gnu.org) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q9VoJ-0005c9-7X for ged-emacs-devel@m.gmane.org; Tue, 12 Apr 2011 07:06:43 +0200 Original-Received: from localhost ([::1]:41853 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9VoI-0005jq-L7 for ged-emacs-devel@m.gmane.org; Tue, 12 Apr 2011 01:06:42 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:46938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9VoD-0005de-R9 for emacs-devel@gnu.org; Tue, 12 Apr 2011 01:06:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9VoA-0003xC-4L for emacs-devel@gnu.org; Tue, 12 Apr 2011 01:06:37 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:40043) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9Vo4-0003wc-W0; Tue, 12 Apr 2011 01:06:29 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id AB18B39E80F5; Mon, 11 Apr 2011 22:06:27 -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 RJLaZrbDJ8Y8; Mon, 11 Apr 2011 22:06:27 -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 39F4739E80DB; Mon, 11 Apr 2011 22:06:27 -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: <83k4f0qijz.fsf@gnu.org> 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 X-Broken-Reverse-DNS: no host name found for IP address 140.186.70.17 Xref: news.gmane.org gmane.emacs.devel:138423 Archived-At: On 04/11/2011 08:01 PM, Eli Zaretskii wrote: > When Emacs saves a buffer or some its portion, > write-region can call emacs_write (though a_write and e_write) with > the full extent of the region to be saved. Ah, sorry, I missed that one. In that case 'int' clearly won't do for the size. > The issue here is that emacs_write and emacs_read are on the boundary: > they accept Emacs Lisp integers, but then call a system API. No, they are regularly passed size_t values as sizes, in other sections of the code. I just now counted, and the 16 calls to emacs_write use int constants 6 times, size_t 5 times, EMACS_INT 3 times, and an int variable once. So, judging by the caller's usages, size_t would seem more appropriate. Furthermore, the API for emacs_write should be designed to let callers know what emacs_write should do. Since emacs_write operates on size values that fit into size_t, that would seem to be the more appropriate type for its size argument.