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
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
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
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
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
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
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
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
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.
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==
10 matches
Mail list logo