This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: memcpy(p,p,len)

On Fri, Apr 30, 2010 at 5:05 PM, Joe Buck <> wrote:
> On Fri, Apr 30, 2010 at 07:30:33AM -0700, Mark Mielke wrote:
>> Just a quick comment than Jan-Benedict's opinion is widely shared by the
>> specification and by the Linux glibc manpage:
>> ? ? ? ? The ?memcpy() ?function ?copies ?n bytes from memory area src to
>> memory
>> ? ? ? ? area dest. ?The memory areas should not overlap. ?Use memmove(3)
>> if the
>> ? ? ? ? memory areas do overlap.
>> It doesn't matter if it sometimes works. Sometimes works programs are
>> sometimes doesn't work programs. :-)
> The typical memcpy function will fail for overlapping but unequal memory
> ranges, but will work for src == dst. ?Switching to memmove would degrade
> performance, and that should only be done if there is an actual, rather
> than a theoretical bug. ?Note that for this use, it's not possible (if
> the program is valid) for the ranges to overlap but be unequal.
> Another alternative is that instead of using memcpy, a specialized
> function could be used that has the required property (the glibc
> memcpy does).

Note that language semantics come in here as well.  The middle-end
assumes that when an assignment is not BLKmode that the RHS
will be read before the lhs will be written.  It does not assume so
otherwise and the behavior is undefined for overlapping *p and *q
if you do *p = *q.  Thus it is up to the frontend to emit a call to
memmove in this case (the C++ frontend got bitten by this and
was fixed).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]