This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] string: Add tests for zero length string inputs


On 22/09/14 18:48, Paul Eggert wrote:
> On 09/22/2014 09:09 AM, Richard Earnshaw wrote:
>> 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.
> 
> I just reread C99 7.1.4 clause 1 and 7.21.2 clause 2, and I don't see 
> that implication.  For example, the following program appears to be 
> strictly conforming:
> 
>     #include <string.h>
> 
>     char src[1];
>     char dst[1];
> 
>     int
>     main (void)
>     {
>       memcpy (dst, src + 1, 0);
>       return 0;
>     }
> 
> Here, src + 1 is a valid pointer even though one cannot safely 
> dereference it.  So it appears to be reasonable to check that memcpy 
> doesn't dereference the source when the size is zero.
> 

Read clause 1 of 7.1.4 again.  "If an argument to a function has an
invalid value ... or a pointer outside of the address space of the
program... the behaviour is undefined."

Ergo, if src+1 can point outside of the address space of the program,
it's undefined behaviour.  And by corollary, it must be safe to
dereference the precise location passed as the argument (but obviously,
not necessarily bytes either side of it).

My reading of those sections also leads me to believe that memcpy could
legitimately expect to perform "*(char*)dst = *(char*)dst", even if the
length is zero.

R.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]