[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: Paul Eggert
Subject: Re: oops? read/write vs type of length parameter
Date: Tue, 12 Apr 2011 08:53:37 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110223 Thunderbird/3.1.8

On 04/12/2011 02:41 AM, Eli Zaretskii wrote:
>> Date: Tue, 12 Apr 2011 01:19:10 -0700
>> From: Paul Eggert <address@hidden>
>> CC: address@hidden, Jim Meyering <address@hidden>
>> I added a runtime check for this, which I don't think
>> will ever fail, but I've been surprised in the past.
> If it ever fails, aborting is too harsh, I think.  The original code
> was well defended against that possibility, see write-region.  It
> would signal an IO error.

If the code is well-defended against passing negative sizes,
then we can remove the checks entirely; they're not needed.
They were meant only as a stopgap in case the callers were
buggy.  (Also please see below.)

>> With that check in place we might as well use size_t for the size,
> Which will cause annoying compiler warnings, at least with some
> optional switches.

Any compiler that will warn about conversions to size_t will
warn about hundreds of other places in Emacs.  These warnings
are more trouble than they're worth, and we shouldn't worry
about them.

>> with the goal of removing the runtime checks once we have
>> carefully checked that they aren't needed.
> Which will never happen, so these aborts will stay in the code
> forever.

I can do it, in the next day or two.  It shouldn't be a problem.

I'm sorry if there are hurt feelings about this, but size_t is
clearly the better choice for buffer sizes; it's the universal
standard in the C API.  ssize_t is never used for that.  And this
is the sysdep.c module after all.

reply via email to

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