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

[Eli Zaretskii]

> From: Jim Meyering <address@hidden>
> Cc: address@hidden
> Date: Mon, 11 Apr 2011 13:08:38 +0200
> 
> Currently, emacs_write silently ignores an invalid buffer length,
> treating it just like a length of 0.  It'd be better not to ignore
> such an error.

emacs_write simply does nothing for negative sizes.  However, its
callers will not silently ignore that: emacs_write returns that same
value to the caller, and callers should (and some do) check the return
value for being non-negative.  See, for example, write-region (whose
debugging led to this change in the interface).

> IMHO, an interface that takes a logically unsigned parameter
> should have an unsigned type.

That would be a major inconvenience, and even annoyance: in Emacs, it
is a very frequent idiom to pass the result of subtracting two
EMACS_INT values, because we reference buffers and strings with such
values.  Having the argument as unsigned type would trigger warnings
and will need explicit type casts.  And with type casts, there's the
danger of interpreting a negative value as a large positive one.

So I think on balance, having a signed type there is better.  The fact
that it is slightly narrower is not a problem in this case: EMACS_INT
is already a couple of bits narrower than the size_t type, so we don't
lose anything.

> I guess I'm biased towards least-surprise for developers, so I
> think read- and write-like functions should accept a buffer length
> argument of type size_t, to be consistent with read and write.

I'm sure you agree that the situation with read and write is less than
ideal.  I don't see why we should follow that in Emacs.  A developer
who sees that a function named emacs_write is called instead of write
should assume that emacs_write is not a trivial wrapper, and should
look there to see the details.

> To try to protect against bugs by changing API to a signed type may
> actually cause trouble when callers end up mixing/comparing their
> newly signed (to accommodate the invented API) and unsigned lengths
> from standard functions.

As I said, the normal use cases in Emacs is that the data types used
to compute that argument are signed to begin with.  And the previous
API used `int', which is also a signed type.

> Another thing to keep in mind: on some older systems, trying to read
> more than INT_MAX bytes in a single syscall will fail.

On such system, emacs_write will return either -1 or a value less than
the last arg, and the caller will notice that and produce a suitable
error message.