[Ffmpeg-devel] [PATCH] avoid useless memcpy with src==dst (valgrind complains)
Sun Jul 23 18:33:41 CEST 2006
> 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
> > (184.108.40.206#2).
> Which part were you replying to?
> 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..
> 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..
More information about the ffmpeg-devel