From owner-cvs-all Sun Oct 20 18:24:22 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A2FE37B401; Sun, 20 Oct 2002 18:24:21 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3BB843E3B; Sun, 20 Oct 2002 18:24:19 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id LAA09830; Mon, 21 Oct 2002 11:24:14 +1000 Date: Mon, 21 Oct 2002 11:35:07 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Poul-Henning Kamp Cc: cvs-committers@FreeBSD.org, Subject: Re: cvs commit: src/sys/kern md5c.c In-Reply-To: <200210202233.g9KMXh4B086499@repoman.freebsd.org> Message-ID: <20021021112456.N9008-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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