emacs-devel
[Top][All Lists]
Advanced

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



reply via email to

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