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

[Rich Felker <dalias at libc dot org>]

On Tue, Sep 23, 2014 at 06:57:53AM -0700, Paul Eggert wrote:
> Richard Earnshaw wrote:
> 
> >if src+1 can point outside of the address space of the program
> 
> As Andreas points out, src+1 does not point outside the address
> space of the program.  It is a valid pointer.

Agree.

> >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.
> 
> I'm sorry, but this reading is incorrect.  If the size is zero,
> memcpy cannot store any bytes into the destination.  Any memcpy that
> does otherwise would break a lot of programs.

Note that even if the dest pointer can legally be dereferenced, it's
absolutely illegal in C11 for memcpy to store anything there (even
rewriting the value that's already there) since it would introduce a
data race and violate the memory model requirements. The importance of
this point cannot be overstated: as of C11, all extraneous writes that
may have been careless, inconsequential implementation details in the
past are now serious implementation bugs!

> >I can think of no reason why 7.21.1/2 would explicitly
> >require valid pointers when the length parameter was 0 unless it was
> >intended that dereferencing could occur.
> 
> It caters to (unusual) architectures that require valid pointers in
> address registers even when the pointers are not dereferenced, e.g.,
> loading a pointer into an address register will trap if the pointer
> is invalid.

Yes. The C standard is written under the assumption that it's
impossible to work with invalid pointers in any way whatsoever. This
is why the _value_ of _any_ pointer object, wherever it may be stored,
becomes an indeterminate value when the pointed-to object's lifetime
ends, and part of why you can't do things like new=realloc(old,n);
if(new==old)...

Rich