Andres Freund <and...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers