This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
__mempcpy vs mempcpy
- From: Michael Eager <eager at mvista dot com>
- To: gcc <gcc at gcc dot gnu dot org>
- Date: Thu, 10 Apr 2003 18:21:42 -0700
- Subject: __mempcpy vs mempcpy
- Organization: MontaVista Software, Inc.
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 at mvista dot com 408-328-8426
MontaVista Software, Inc. 1237 E. Arques Ave., Sunnyvale, CA 94085