Re: [PATCHES] fix memcpy() overlap

2004-02-03 Thread Neil Conway
Tom Lane <[EMAIL PROTECTED]> writes: > If we want to get rid of the valgrind warning, a simpler patch would > be to substitute memmove for memcpy I've made this change and committed it to HEAD. -Neil ---(end of broadcast)--- TIP 6: Have you search

Re: [PATCHES] fix memcpy() overlap

2004-02-03 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Isn't memmove() for overlaping regions? That's what my BSD manual page > says. If we want to get rid of the valgrind warning, a simpler patch would be to substitute memmove for memcpy in that particular numeric.c subroutine (at least, I assume this will

Re: [PATCHES] fix memcpy() overlap

2004-02-03 Thread Bruce Momjian
Tom Lane wrote: > 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

Re: [PATCHES] fix memcpy() overlap

2004-02-02 Thread Tom Lane
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 t

Re: [PATCHES] fix memcpy() overlap

2004-02-02 Thread Andrew Dunstan
Stephan Szabo wrote: On Mon, 2 Feb 2004, Tom Lane wrote: Neil Conway <[EMAIL PROTECTED]> writes: I don't know of a memcpy() implementation that would actually bail out if called with two equal pointers, but perhaps there is one in existence somewhere. This isn't a bug, and I see

Re: [PATCHES] fix memcpy() overlap

2004-02-02 Thread Michael van Elst
On Mon, Feb 02, 2004 at 01:23:15PM -0800, Stephan Szabo wrote: > > Isn't memcpy on overlapping (even entirely overlapping) buffers undefined > behavior unless the count is 0? The C standard says: "If copying takes place between objects that overlap, the behaviour is undefined". SUSv3 says the sam

Re: [PATCHES] fix memcpy() overlap

2004-02-02 Thread Stephan Szabo
On Mon, 2 Feb 2004, Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > I don't know of a memcpy() implementation that would actually bail out > > if called with two equal pointers, but perhaps there is one in > > existence somewhere. > > This isn't a bug, and I see no reason to clutter

Re: [PATCHES] fix memcpy() overlap

2004-02-02 Thread Neil Conway
Tom Lane <[EMAIL PROTECTED]> writes: > This isn't a bug If that's the case I'm content with not changing the code, but I'd rather not just take it on faith: can you point me to some authority that says two objects with the same address do not "overlap"? (I checked C99 (draft 843) and while it ref

Re: [PATCHES] fix memcpy() overlap

2004-02-02 Thread Tom Lane
Neil Conway <[EMAIL PROTECTED]> writes: > I don't know of a memcpy() implementation that would actually bail out > if called with two equal pointers, but perhaps there is one in > existence somewhere. This isn't a bug, and I see no reason to clutter the code just to shut up valgrind.

[PATCHES] fix memcpy() overlap

2004-02-02 Thread Neil Conway
Another error reported by valgrind on the postmaster (& children) is the following: ==30568== Source and destination overlap in memcpy(0xBFFFEA30, 0xBFFFEA30, 24) ==30568==at 0x40024224: memcpy (mac_replace_strmem.c:93) ==30568==by 0x82081F3: set_var_from_var (numeric.c:2732) ==30568==