Re: valgrind overlapping memcpy warning on log addressing branch

2013-10-15 Thread Stefan Fuhrmann
On Tue, Oct 15, 2013 at 4:56 PM, Philip Martin wrote: > I get the following when running fs-fs-pack-test 1: > > ==18975== Source and destination overlap in memcpy(0x84c2190, 0x84c2191, 7) > ==18975==at 0x4C2A690: memcpy (mc_replace_strmem.c:838) > ==18975==by 0x412F5F0: svn_prefix_string__

Re: valgrind overlapping memcpy warning on log addressing branch

2013-10-15 Thread Philip Martin
Philip Martin writes: > Branko Čibej writes: > >> Memcpy is not guaranteed to copy data in order of increasing addresses; or >> in fact any specific order. It has to be memmove. > > Indeed, memmove is correct if the source and destination overlap but I'm > not yet sure whether the bug is the ove

Re: valgrind overlapping memcpy warning on log addressing branch

2013-10-15 Thread Philip Martin
Branko Čibej writes: > Memcpy is not guaranteed to copy data in order of increasing addresses; or > in fact any specific order. It has to be memmove. Indeed, memmove is correct if the source and destination overlap but I'm not yet sure whether the bug is the overlap or the use of memcpy. Similar

Re: valgrind overlapping memcpy warning on log addressing branch

2013-10-15 Thread Branko Čibej
Memcpy is not guaranteed to copy data in order of increasing addresses; or in fact any specific order. It has to be memmove. On 15 Oct 2013 15:57, "Philip Martin" wrote: > I get the following when running fs-fs-pack-test 1: > > ==18975== Source and destination overlap in memcpy(0x84c2190, 0x84c21