[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: |
Jim Meyering |
Subject: |
Re: oops? read/write vs type of length parameter |
Date: |
Mon, 11 Apr 2011 14:27:36 +0200 |
Eli Zaretskii wrote:
>> 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.
>From my experience with signedness-related warnings,
it is counterproductive to enable options like -Wsign-conversion
and -Wsign-compare, unless you're prepared to cherry-pick fixes for
the few "real" problems and to ignore the others. Adding casts to work
around them makes the "cure" worse than the disease.
> 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.
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.
- oops? read/write vs type of length parameter, Jim Meyering, 2011/04/11
- Re: oops? read/write vs type of length parameter, Eli Zaretskii, 2011/04/11
- Re: oops? read/write vs type of length parameter, Jim Meyering, 2011/04/11
- Re: oops? read/write vs type of length parameter, David Kastrup, 2011/04/11
- Re: oops? read/write vs type of length parameter, Eli Zaretskii, 2011/04/11
- Re: oops? read/write vs type of length parameter,
Jim Meyering <=
- Re: oops? read/write vs type of length parameter, David Kastrup, 2011/04/11
- Re: oops? read/write vs type of length parameter, Jim Meyering, 2011/04/11
- Re: oops? read/write vs type of length parameter, Eli Zaretskii, 2011/04/12
- Re: oops? read/write vs type of length parameter, Ted Zlatanov, 2011/04/12
- Re: oops? read/write vs type of length parameter, Eli Zaretskii, 2011/04/12
- Re: oops? read/write vs type of length parameter, Ted Zlatanov, 2011/04/12
- Large file support (was: oops? read/write vs type of length parameter), Eli Zaretskii, 2011/04/12
- Re: oops? read/write vs type of length parameter, Michael Welsh Duggan, 2011/04/14
- Re: oops? read/write vs type of length parameter, Eli Zaretskii, 2011/04/11
Re: oops? read/write vs type of length parameter, Stephen J. Turnbull, 2011/04/11