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: oops? read/write vs type of length parameter Date: Tue, 12 Apr 2011 09:38:19 -0400 Message-ID: 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> <51964.130.55.132.62.1302611550.squirrel@webmail.lanl.gov> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1302616466 31237 80.91.229.12 (12 Apr 2011 13:54:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 12 Apr 2011 13:54:26 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: herring@lanl.gov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 12 15:54:22 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 1Q9e2w-0006GR-FQ for ged-emacs-devel@m.gmane.org; Tue, 12 Apr 2011 15:54:22 +0200 Original-Received: from localhost ([::1]:57941 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9e2w-0002wn-3S for ged-emacs-devel@m.gmane.org; Tue, 12 Apr 2011 09:54:22 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:55848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9e2t-0002rY-El for emacs-devel@gnu.org; Tue, 12 Apr 2011 09:54:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9dnW-0003te-Hu for emacs-devel@gnu.org; Tue, 12 Apr 2011 09:38:27 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:60256) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9dnW-0003tZ-EQ for emacs-devel@gnu.org; Tue, 12 Apr 2011 09:38:26 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Q9dnP-0004ec-Tt; Tue, 12 Apr 2011 09:38:19 -0400 In-reply-to: <51964.130.55.132.62.1302611550.squirrel@webmail.lanl.gov> (herring@lanl.gov) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:138437 Archived-At: > Date: Tue, 12 Apr 2011 05:32:30 -0700 (PDT) > From: "Davis Herring" > Cc: "Eli Zaretskii" , emacs-devel@gnu.org > Reply-To: herring@lanl.gov > > >> 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. > > This has been said several times, apparently assuming that the whole > length _must_ be passed. But other callers call these functions with > small arguments in a loop. AFAIK, only one caller does that, to send data to a subprocess. Such piecemeal writes are justified in that case, because (AFAIK) pipes are generally limited in how much stuff they can hold, and because async communications with other processes are relatively slow anyway. > Can't that be used (with perhaps more like 64 MiB than 64 KiB per > call) for these large files too? That would just slow down Emacs's I/O for no good reason. We should trust the OS that it knows better how to optimize disk I/O. OTOH, nothing is lost by using ssize_t data type to write the whole buffer, because Emacs cannot have buffers that large anyway: we reserve a small number of bits for Lisp tags, and therefore the largest value we could ever put in that argument is MOST_POSITIVE_FIXNUM, which is always less than what ssize_t can hold.