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

[Michael Welsh Duggan <md5i@md5i.com>]

Jim Meyering <jim@meyering.net> writes:

> David Kastrup wrote:
>> Jim Meyering <jim@meyering.net> writes:
>>
>>> What about when EMACS_INT is defined to "int"?
>>>
>>> Someone will inevitably call your write-like function
>>> with a length of type size_t -- many existing uses do just that --
>>> and by using a signed type, you will have converted their long
>>> yet valid (2-4GiB), buffer length, into a negative number.
>>
>> Resulting in an error or nothing happening.  In contrast, if a negative
>> number is turned into a long yet valid (2-4GiB) number, it is very
>> likely that unintended memory areas will get stomped over.
>
> Since someone mentioned a goal of being able to edit a 2GiB
> file, I thought people here would be sensitive to an API policy
> that renders that goal unreachable on some systems.
>
> Of course the extra bit doesn't matter when you start with 64,
> but starting with only 32, using an unsigned "length" would
> avoid that unnecessary limit.

Forgive me if this is already known, but I believe the POSIX standard
says that "If the value of nbyte is greater than {SSIZE_MAX}, the result
is implementation-defined."  This implies that there is no guarantee
that the extra bit would ever be reliably used anyway.

-- 
Michael Welsh Duggan
(md5i@md5i.com)