Re: oops? read/write vs type of length parameter

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 12 Apr 2011 05:32:30 -0700 (PDT)
> From: "Davis Herring" <herring@lanl.gov>
> Cc: "Eli Zaretskii" <eliz@gnu.org>, 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.