2013-02-17 16:32 keltezéssel, Tom Lane írta:
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.
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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
