[Ffmpeg-devel] [PATCH] avoid useless memcpy with src==dst (valgrind complains)
Sun Jul 23 17:35:59 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
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.
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?
> > Anyway, this is not really what interests me, I'd prefer to know that
> > even if it is a compiler bug, may I apply the patch or do you prefer if
> > I don't?
> 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:
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>
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...
And looking at the MPlayer binary (haven't checked if it's the same when
compiling ffmpeg I admit) there is:
5d081a: ba 58 00 00 00 mov $0x58,%edx
5d081f: 48 89 ee mov %rbp,%rsi
5d0822: 48 89 e7 mov %rsp,%rdi
5d0825: e8 86 c1 e4 ff callq 41c9b0 <memcpy at plt>
5d082a: ba 58 00 00 00 mov $0x58,%edx
5d082f: 4c 89 e6 mov %r12,%rsi
gcc version 4.1.1 (Gentoo 4.1.1)
on AMD64 here.
More information about the ffmpeg-devel