__mempcpy vs mempcpy

[Michael Eager]

After updating cygwin recently, gcc doesn't build.  It attempts
to link __mempcpy, which cygwin doesn't supply.  Cygwin does
provide mempcpy.  (Which apparently has been an issue in the 
past, because at one time it was declared in string.h but not 
actually included in the library.)

The oddness is that gcc configure checks for mempcpy, while
gcc code actually references __mempcpy.    

There are refs to both mempcpy and __mempcpy:

gcc/intl/loadmsgcat.c:
# if defined _LIBC || HAVE_MEMPCPY
          *((char *) mempcpy (charset, charsetstr, len)) = '\0';
# else
          memcpy (charset, charsetstr, len);
          charset[len] = '\0';
# endif

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

In gcc/intl/localealias.c, the code looks like loadmsgcat.c, 
except that there's also the following:

#ifdef _LIBC
. . .
# ifndef mempcpy
#  define mempcpy __mempcpy
# endif
# define HAVE_MEMPCPY   1
#endif

So questions:

1)  Should configure be checking for mempcpy when it uses __mempcpy?
2)  Should all uses be either mempcpy or __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.
4)  Why bother with mempcpy when it seems to be such a trivial
    modification of memcpy?

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


--
Michael Eager     eager@mvista.com	408-328-8426	
MontaVista Software, Inc. 1237 E. Arques Ave., Sunnyvale, CA  94085