2013-02-17 16:32 keltezéssel, Tom Lane írta:
> Andres Freund <andres@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.
Then, why isn't memcpy() skipped if the source and dest are the same?
It would be a micro-optimization but a valid one.
> 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
>
>
--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de http://www.postgresql.at/
