Subject: Re: kern/2572: kernel could use memcpy/memmove/memset to its own advantage
To: None <tech-kern@NetBSD.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: tech-kern
Date: 07/25/1996 07:00:39
> 	#define bcopy(s, t, n)		memcpy(t, s, n)
> 	#define ovbcopy(s, t, n)	memmove(t, s, n)
> 	#define bzero(s, n)		memset(s, 0, n)

> Compilers like gcc "know" about memcpy, memmove and memset and can
> replace the function calls with equivalent code when appropriate.
> This is not true with the traditional BSD bcopy, ovbcopy, and bzero
> functions currently used.

ovbcopy is "traditional"?  Traditionally, bcopy() has had memmove()
semantics - I'd always assumed it was just a wrapper around the VAX
movc3 instruction, though if it existed on PDP-11 Unices that's
obviously a bogus derivation - and I don't think I've ever heard of
ovbcopy() before.  ("traditionally" here means, approximately, "4.3
back when I worked with it on a VAX".)

> Changing all the source files to use those functions [ie, mem*] is
> perhaps a better solution.

That at least would avoid people getting bitten by our kernel bcopy()
not having the semantics they expect from bcopy().  (Indeed, our
user-land bcopy() has memmove() semantics, at least according to the
manpage.)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu
		    01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D