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