This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
bcopy -> memcpy/memmove transition proposal
- To: egcs at cygnus dot com
- Subject: bcopy -> memcpy/memmove transition proposal
- From: Per Bothner <bothner at cygnus dot com>
- Date: Thu, 17 Sep 1998 00:08:49 -0700
It is really ridiculous that gcc still uses the non-ANSI functions
(such as bcopy), rather than the standard ANSI functions. We all
(I hope) agree this is bogus, but fixing them all is a hassle.
Here is a concrete suggestion for how we can deal with a mix
of both styles, and fix them as convenient.
1) Add memcpy, memmove, memzero, strchr, and strrchr to
the list of functions in the AC_CHECK_FUNCS macro in configure.in.
2) Add a new file string.c, which is always linked in.
This would look something like:
#include <config.h>
#include "gansidecl.h"
#ifdef __STDC__
#include <stddef.h>
#else
#define size_t unsigned long
#endif
#ifndef HAVE_BCOPY
#undef bcopy
void
bcopy (src, dest, len)
register char *src, *dest;
int len;
{
if (dest < src)
while (len--)
*dest++ = *src++;
else
{
char *lasts = src + (len-1);
char *lastd = dest + (len-1);
while (len--)
*(char *)lastd-- = *(char *)lasts--;
}
}
#enidf /* !HAVE_BCOPY */
#ifdef HAVE_MEMCPY
PTR
memcpy (out, in, length)
PTR out;
CONST PTR in;
size_t length;
{
bcopy(in, out, length);
return out;
}
#endef /* ! HAVE_MEMCPY */
#ifdef HAVE_MEMMOVE
PTR
memmove (s1, s2, n)
PTR s1;
CONST PTR s2;
size_t n;
{
bcopy (s2, s1, n);
return s1;
}
#endif /* !HAVE_MEMMOVE */
There are some issues I'm not sure about:
1) Do we need to add prototypes for bcopy, memmove and/or memcpy
to some header file, if they are "missing"?
I don't see any necessity, or reason why it would be desirable,
but may be missing something.
2) Is there a problem with build vs host? Is is the difference
between auto-host.h and auto-config.h? I'm not clear on how
this happens; perhaps we may need to compile string.c twice,
once for build and once for host.
Comments? This suituation has been bugging for a long time, and
I think it is time to fix it.
--Per Bothner
Cygnus Solutions bothner@cygnus.com http://www.cygnus.com/~bothner