> That was it; bcmp and bcopy.
> 
> Shouldn't we be EOL'ing those in favor of memcmp and memcpy (and
> memmove)?  It seems awfully silly to have an additional interface in
> the user namespace which is completely redundant with an interface
> in the implementation namespace.

I think that "backwards compatibility" requires us to provide the b*
functions.  However, it may make sense to change them to be wrappers
around the mem* equivalents.  The optimized assembly versions are
often many times bigger due to special case handling of alignment,
loop unrolling, etc.; and there isn't that much reason to have
multiple versions of essentially the same code in our libraries.

Another advantage of using the Standard C mem* functions is that good
compilers are able to inline them when they find it advantageous.
This is most useful on machines like the iX86 with block memory
instructions, but can be of benefit on others as well.  The current
gcc is able to inline memcpy and memcmp.  I have submitted changes
which add memset(buf, 0, n) which will be in a future gcc release.

Since there is a lot of code that still uses old api, macros in
<string.h> that convert the old to the new could be added.  This will
avoid the extra layer of function call overhead.  Unfortunately those
programs that use b* without including that header would still lose.

Another advantage of the macro technique is that you don't have to
change all the instances the functions are used.  I think this is most
important for the kernel, where we have some interest in being "diff"
compatible with other 4.4BSD derrived systems.  Changing everything to
use mem* would create many differences.  This would make it more
difficult to separate out important changes.

> (I wouldn't mind seeing memzero added, either.)

I don't think that there's much of a point.  The time needed to
replicate bytes to fill a word is very small.  It would only matter if
the length was very small.  In those cases, the compiler may inline
the zero anyway.

> Anyway, thanks for all the advice; sure enough, the updated
> .S files compiled and built.
> 
> All is well.

Sorry about that folks, I made some stupid errors which would have
shown up if I had used these functions in a real systems, but all my
testing as of late has been in a performance test-rig.  :-(

	--jtc