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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 11 Apr 2011 22:06:21 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> 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 same is true for emacs_read, btw; see insert-file-contents.

> > 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.

Granted, I reviewed all those other callers when I made my change.
All those I left at their original form are passing small values in
this argument.  In particular, all the callers that use size_t get
those values by calling strlen on short strings.  And int is obviously
not a problem at all.

So this theoretical issue has no practical consequences in the case in
point.

However, if it's deemed good practice to make them 100% bulletproof,
I'm not opposed to change them all use EMACS_INT or ssize_t, although
that would require type casts that I deplore.

> 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.

As was already explained here, this has downsides that are more
serious than the current use of ssize_t (as long as programming
mistakes are concerned).  So this suggestion I do oppose.