Re: overlapping strncpy/memcpy errors via valgrind

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-02-17 15:10:35 +0000, Greg Stark wrote:
>> Peter G is sitting near me and reminded me that this issue came up in the
>> past. Iirc the conclusion then is that we're calling memcpy where the
>> source and destination pointers are sometimes identical. Tom decided there
>> was really no realistic architecture where that wouldn't work.

> I am not so convinced that that is safe if libc turns that into some
> optimized string instructions or even PCMPSTR...

What would you envision happening that would be bad? The reason
overlapping source/dest is undefined is essentially that the function is
allowed to copy bytes in an unspecified order. But if the pointers are
the same, then no matter what it does, no individual store will replace
a byte with a different value than it had, and so it's not possible for
the order of operations to matter.

I don't think it's worth contorting the source code to suppress this
complaint. In the case of resolve_polymorphic_tupdesc, for instance,
dodging this warning would require that we not use TupleDescInitEntry to
update the data type of an attribute, but instead have this code know
all about the subsidiary fields that get set from the datatype. I'm not
seeing that as an improvement ...

regards, tom lane