[Ffmpeg-devel] [PATCH] avoid useless memcpy with src==dst (valgrind complains)

[Wolfram Gloger]

> On Sun, Jul 23, 2006 at 02:24:17PM -0000, Wolfram Gloger wrote:
> > > Though for src == dst I doubt any memcpy function will break
> > > stuff. And for the overlapping case when src != dst does the C standard
> > > specify the behaviour?
> > 
> > Using memcpy() on overlapping objects is undefined behaviour
> > (7.21.2.1#2).
> 
> Which part were you replying to?

The second.

> If to the first: memcpy may strictly
> speaking have undefined behaviour for src == dst, but I very much doubt
> it has in reality.

I agree, but it's better to be safe.

> If to the second part: I meant if you have two "struct something"
> pointers a and b, is the behaviour of *a = *b defined when the areas for
> *a and *b overlap?

Only if the overlap is exact, i.e. a == b.
Which is in fact the case here (if there is overlap at all).

> > Patch looks fine to me anyway, but I think it should be investigated
> > how on earth memcpy() is generated here.
> 
> objdump -S on utils.o gives me:
> [...]
>     temp= *buf;
>      18a:       ba 58 00 00 00          mov    $0x58,%edx
>      18f:       48 89 ee                mov    %rbp,%rsi
>      192:       48 89 e7                mov    %rsp,%rdi
>      195:       e8 00 00 00 00          callq  19a <avcodec_default_release_buffer+0x7a>
>     *buf= *last;
>      19a:       ba 58 00 00 00          mov    $0x58,%edx
>      19f:       4c 89 e6                mov    %r12,%rsi
> [...]
> 
> so there definitly is some placeholder for some call...

Indeed.  I would have expected something like __builtin_memcpy to be
generated and inlined..

> using
> gcc version 4.1.1 (Gentoo 4.1.1)
> on AMD64 here.

I see.  Perhaps they simply rely on the fact that their memcpy() works
fine for the exact overlap case.  Then valgrind shouldn't complain on
such a platform..

Regards,
Wolfram.