This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] string: Add tests for zero length string inputs
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Will Newton <will dot newton at linaro dot org>, Ondr(ej Bílka <neleai at seznam dot cz>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 23 Sep 2014 13:57:59 +0100
- Subject: Re: [PATCH] string: Add tests for zero length string inputs
- Authentication-results: sourceware.org; auth=none
- References: <1410910830-20900-1-git-send-email-will dot newton at linaro dot org> <20140919112302 dot GA2912 at domone> <CANu=Dmgn75GZU8my6fcCp1AyJRw8jEJVhaGTD+5mjOrXB_ENGw at mail dot gmail dot com> <542049A4 dot 1070409 at arm dot com> <54216A74 dot 5090405 at redhat dot com>
On 23/09/14 13:41, Florian Weimer wrote:
> On 09/22/2014 06:09 PM, Richard Earnshaw wrote:
>>> These tests are not testing null pointers, they are testing that when
>>> given a zero length the functions actually read/write zero bytes.
>>> Whether the specification demands that behaviour is arguable but I
>>> believe that it is the most sane behaviour.
>
>> Valid pointers is more than just non-NULL. In particular, it implies
>> that is safe to dereference the addressed byte in a source operand even
>> when the length parameter is zero.
>
> Valid pointers can also point one element past the end of an array of
> objects.
I don't think such a pointer forms a valid argument for a library
function though. See my previous reply to Paul.
> Such pointers can occur naturally during the final iteration
> of buffer-processing loops. I don't think it is reasonable to expect
> that programmers write special code (or at least early loop exits) to
> deal with this corner case. This has to work, and if the C standard
> does not guarantee it does, it needs fixing.
>
>> Thus testing that no bytes are read would be incorrect.
>
> I disagree, per the above.
>
R.