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

Rich Felker dalias
Mon Jul 24 08:52:11 CEST 2006


On Sun, Jul 23, 2006 at 09:20:50PM +0100, M?ns Rullg?rd wrote:
> 
> Rich Felker said:
> > On Sun, Jul 23, 2006 at 05:35:59PM +0200, Reimar D?ffinger wrote:
> >> Hello,
> >> 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? 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?
> >
> > That's an interesting question. *a = *b may be undefined when a and b
> > both point to the same object; I'm not sure. Anyone care to dig up
> > this info?
> 
> The objects must overlap exactly or not at all. Otherwise the result is
> undefined.

Then gcc is incorrect in calling memcpy. It must call memmove. Since
gcc can have no idea about the C library implementation, it can't know
if memcpy is safe for exactly-overlapped objects or not..

Of course on x86 it should just inline the "rep movsd" anyway. Not
only is it faster than calling memcpy; it's also fewer bytes than it
would take to setup a function call and doesn't clobber the
call-clobbered registers.

Rich





More information about the ffmpeg-devel mailing list