[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael Welsh Duggan
Subject: Re: oops? read/write vs type of length parameter
Date: Thu, 14 Apr 2011 16:57:43 -0400
User-agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux)

Jim Meyering <address@hidden> writes:

> David Kastrup wrote:
>> Jim Meyering <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]