This is the mail archive of the mailing list for the glibc 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: [RFC] Do not call memmove when memcpy suffices.

On Aug 13, 2013, OndÅej BÃlka <> wrote:

>      char *dest = (_dest);
>      char *src = (_src);
>      size_t n = (_n);

dest, src and n are in the user namespace; we have to use symbols in the
implementation namespace.

>      if (__glibc_likely ((size_t)((src - n) - dest) >= 2 * n))

Is this test really safe?  I'm thinking about arches with segmented
memory and stuff, so that the difference between unrelated pointers may
not make much sense or even fit in a size_t.  I'm not sure we support
any such architecture.

>        return memmove (dest, src, n);

If we take this route of optimizing memmove with a macro, we'll probably
want a distinct symbol to signal that we have already determined that
there's an overlap and we need the extra complexity, rather than calling
a function that might perform the test again.

But then, we might as well expose this symbol to users.  Arguably,
memmove already is such exposed symbol and we shouldn't make a redundant
test when the caller has already determined that a specific mem copying
operation needs memmove.

What I'm getting at here is that, if we're going to do this, we should
probably have 3 entry points:

- memcpy: caller knows there's no overlap
- __memmove: caller knows there is an overlap
- memmove: caller doesn't know; test and call one of the above

Alexandre Oliva, freedom fighter
You must be the change you wish to see in the world. -- Gandhi
Be Free! --   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

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