Date: Mon, 21 Oct 2002 11:35:07 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Poul-Henning Kamp <phk@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/sys/kern md5c.c Message-ID: <20021021112456.N9008-100000@gamplex.bde.org> In-Reply-To: <200210202233.g9KMXh4B086499@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 20 Oct 2002, Poul-Henning Kamp wrote: > phk 2002/10/20 15:33:43 PDT > > Modified files: > sys/kern md5c.c > Log: > We have memset() and memcpy() in the kernel now, so we don't need to > #define them to bzero and bcopy. > > Spotted by: FlexeLint > > Revision Changes Path > 1.20 +0 -5 src/sys/kern/md5c.c I still disagree with putting memset() and memcmp() in the kernel, and don't have them in mine. memset() has a low quality implementation and memcmp() has a plain broken implementation (memcmp() can't be implemented using bcmp() since it returns a tri-state value but bcmp() returns a binary value, but it is). Users of memcmp() in the kernel have to know that it is just a wrapper for bcmp() and not use its third state. The can even more easily just use bcmp(). The bogusness of using memcpy() instead of bcopy() is a little different. Long ago, some calls to bcopy() were converted to calls to memcpy() to take advantage of gcc's inline memcpy() which was more efficient for small fixed-sized (aligned) copies, at least on i386's. memcpy() was supposed to be used for precisely these copies. A non-inline memcpy() was added to support certain cases where gcc didn;t do the inlining (mainly for compiling with -O0). Not so long ago, this was bogotifed by turning off all gcc inlining using -fno-inline. My kernel still has memcpy() since there are too many calls to it to fix. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021021112456.N9008-100000>