Re: bcopy -> memcpy/memmove transition proposal

[Per Bothner <bothner at cygnus dot com>]

> 1.  Wasn't using the BSD style a GNU coding convention at some point?

In the old days, there were two main styles of Unix:  "USG" (System 5),
and "BSD".  The GNU preference was for BSD, when there was a choice.
This distinction is now completely meaningless.  Now, the default
should be Posix, unless there is a good readon not to.

> In fact, I recall something on gcc2 within the last 1-1.5
> years where someone asked kenner if it was time to switch and he
> rejected it for some reason.

Kenner just thought it was more work than worth doing, plus a risk
of destabilizing mistakes when converting.  But if we do it so
both sets of functions can be used, the risk is reduced, since we
don't have to do an all-or-nothing conversion.  (Plus of course it
is much easier now that we use autoconf.)

> If you do "foo = memcpy()" I think you lose if
> sizeof(int)!=sizeof(ptr) and no prototype exists.

The GNU coding standards recommends against doing that, and I concur.

> The main obstacle AFAICT is that in order to use libiberty correctly,
> you have to include libiberty.h which includes ansidecl.h.

This is certainly not necessary for using the mem* functions.

The main issue I see is which approach will require less Makefile
and configure hacking.  The actual *code* for memmove etc is trivial.
Yes, it is nice to avoid duplications, but it is not that big a deal.

The situation would be simplified if the host programs (such as gen*.c)
did not require the string functions.  I see most of them define
their own - using a simple mybcopy function.  But genattr.c and
genattrtab.c use plain bcopy.  Anyone knows why the inconsistency?

If we only have to deal with the programs that run on host,
we could just link with ../libiberty/libiberty.a.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner