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

[David Kastrup <dak@gnu.org>]

Jim Meyering <jim@meyering.net> writes:

> 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.
>
> IMHO, an interface that takes a logically unsigned parameter
> should have an unsigned type.

In that case, there _are_ no invalid buffer lengths since any invalid
length is turned into a humongous valid one.

Since the starting value is from EMACS_INT...

> 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 prefer surprise while reading the prototypes to surprise while
actually calling the function.  A reinterpretation of signed numbers
into the unsigned realm is not going to cause much joy here.

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

In C, (-1 > 10U) is true.  In practice, unsigned types cause much more
trouble and confusion than they avoid.

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

Are you trying to argue for or against your proposal?

-- 
David Kastrup