cvs commit: src/sys/alpha/alpha support.s src/sys/i386/i386 identcpu.c support.s src/sys/i386/include md_var.h src/sys/i386/isa npx.c src/sys/ia64/ia64 support.s src/sys/powerpc/powerpc bcopy.c sr

[M. Warner Losh]

In message: <20030405160449.L37042 at gamplex.bde.org>
            Bruce Evans <bde at zeta.org.au> writes:
: > The existence of ovbcopy()?  I imagine it was just an API issue,
: > someone didn't feel comfortable assuming that the kernel bcopy()
: > handles overlap when the userland version doesn't.  In FreeBSD
: 
: I think the problem is more the reverse.  The userland bcopy() has handled
: overlap (and has been documented to do so) since at least FreeBSD-1.1.
: It's hard to see how the BSD bcopy() family could work if bcopy() didn't
: handle overlap, since this family has no other member corresponding to
: Standard C's memmove().

Actually ovbcopy was introduced in some of the Sys V or Sys III
ports when people found they could (or thought they could) write
'memcpy' faster than 'memmove' and it matter enough to go through
their source code trees and hack the overlap cases to deal with
ovbcopy.  In BSD land bcopy has always ment what we spell these days
as 'memmove'.  In the middle 1980's there was a lot of ifdefs to deal
with all this madness, and I think only IRIX and/or HP-UX were the
only machines that changed the API of bcopy to mean 'memcpy' and had
ovbopy for the overlapping cases, but I couldn't find anything in my
ancient collection of unix books tonight to back up my vague memory.

Warner