Re: __mempcpy vs mempcpy

[DJ Delorie <dj at redhat dot com>]

> which looks almost identical to libiberty/regex.c:
> #if defined HAVE_MEMPCPY || defined _LIBC
>           *((char *) __mempcpy (errbuf, msg, errbuf_size - 1)) = '\0';
> #else
>           memcpy (errbuf, msg, errbuf_size - 1);
>           errbuf[errbuf_size - 1] = 0;
> #endif

This looks like a bug in the libiberty sources.  Regex is (was)
mirrored from glibc, which probably didn't have to worry about that
kind of portability.  (glibc now uses a different regex).  Does it
actually fail because of this code?  We don't actually check for
mempcpy() in libiberty (although if you want to add that check to
libiberty, the patch would be welcome ;).

Unfortunately, I suspect cygwin may trip over this "incompatibility"
with glibc in the future, in other sources.

Assuming you mean libiberty for the rest...

> 2)  Should all uses be either mempcpy or __mempcpy?

mempcpy

> 3)  The define for HAVE_MEMPCPY in localealias.c looks hinky. 
>     after all, if you don't have mempcpy, then renaming it __mempcpy
>     isn't much help.

_LIBC means you're compiling glibc itself, or linking with glibc.  I
think that code is an attempt to use __mempcpy if memcpy is not
already a macro, not if it doesn't exist.

> 4)  Why bother with mempcpy when it seems to be such a trivial
>     modification of memcpy?

Sounds like it might be a trivially faster function, since it doesn't
need to keep track of the pointer that memcpy would have to return.

> There's a bunch of ways to fix this.  Suggestions?

For the libiberty/regex.c bug, please feel free to post a patch for
__mempcpy -> mempcpy.  Consider it pre-approved.

Note that we never check for mempcpy() in libiberty anyway, so that
code won't ever get used (unless _LIBC is defined).

I suspect the non-libiberty sources would want a similar patch.