Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> On Mon, 2 Feb 2004, Tom Lane wrote:
>> This isn't a bug, and I see no reason to clutter the code just to shut
>> up valgrind.
> Isn't memcpy on overlapping (even entirely overlapping) buffers undefined
> behavior unless the count is 0?
The reason that the spec describes overlapped memcpy as undefined is
that it does not want to restrict which direction the copy occurs in
(proceeding from lower to higher memory addresses or vice versa).
memmove is constrained to do the copy in the direction that will avoid
failure when the source and destination partially overlap. But memcpy
is expected to do whichever is fastest on the particular architecture,
without concern for possible overlap. (Offhand I've never heard of a
machine where memcpy doesn't work lower-to-higher, but maybe there is
one.)
However, when the source and destination buffers are the same, it does
not matter which direction you copy in; you are picking up and putting
down the same bytes at the same addresses no matter what order you
process the bytes in. There is no implementation in existence that will
produce an unwanted result.
If you want to argue about dependencies on implementation details that
are theoretically undefined according to the ANSI C spec, we have tons
more beyond this one. F'r instance, depending on twos-complement
arithmetic is illegal per spec also ...
regards, tom lane
