This is the mail archive of the
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:
#define size_t unsigned long
bcopy (src, dest, len)
register char *src, *dest;
if (dest < src)
*dest++ = *src++;
char *lasts = src + (len-1);
char *lastd = dest + (len-1);
*(char *)lastd-- = *(char *)lasts--;
#enidf /* !HAVE_BCOPY */
memcpy (out, in, length)
CONST PTR in;
bcopy(in, out, length);
#endef /* ! HAVE_MEMCPY */
memmove (s1, s2, n)
CONST PTR s2;
bcopy (s2, s1, n);
#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.
Cygnus Solutions email@example.com http://www.cygnus.com/~bothner