Stephan Szabo <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend