From owner-cvs-src@FreeBSD.ORG Thu Mar 10 09:05:11 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23B7F16A4CE; Thu, 10 Mar 2005 09:05:11 +0000 (GMT) Received: from storm.uk.FreeBSD.org (storm.uk.FreeBSD.org [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82F6C43D5D; Thu, 10 Mar 2005 09:05:10 +0000 (GMT) (envelope-from mark@grondar.org) Received: from storm.uk.FreeBSD.org (uucp@localhost [127.0.0.1]) by storm.uk.FreeBSD.org (8.13.1/8.13.1) with ESMTP id j2A959F2099849; Thu, 10 Mar 2005 09:05:09 GMT (envelope-from mark@grondar.org) Received: (from uucp@localhost)j2A959kx099847; Thu, 10 Mar 2005 09:05:09 GMT (envelope-from mark@grondar.org) Received: from grondar.org (localhost [127.0.0.1]) by grovel.grondar.org (8.13.3/8.13.1) with ESMTP id j2A91MeN081641; Thu, 10 Mar 2005 09:01:22 GMT (envelope-from mark@grondar.org) Message-Id: <200503100901.j2A91MeN081641@grovel.grondar.org> X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Colin Percival From: Mark Murray In-Reply-To: Your message of "Thu, 10 Mar 2005 00:38:08 PST." <42300770.7040409@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Mar 2005 09:01:22 +0000 Sender: mark@grondar.org cc: Peter Jeremy cc: src-committers@FreeBSD.ORG cc: Mark Murray cc: cvs-all@FreeBSD.ORG cc: cvs-src@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libmd Makefile sha256.3 sha256.h sha256c.c shadriver.c src/sbin/md5 Makefile md5.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 09:05:11 -0000 Colin Percival writes: > > But they do have bugs fixed or are optimised. > > Optimized? Perhaps. Bugs fixed? Almost certainly not -- writing a > hash implementation which works for all the test vectors while failing > for some other data would be very difficult. There's only one code > path through the compression function, and only a very small number > through the wrappers -- if you get something wrong, it's going to bite > you every time. I'm glad you said _almost_ certainly not. Subtle edge cases can crop up in the most nasty ways when you move to different architectures, etc. In other cases, assumptions about the test data can get you in trouble. EG - I haven't tested this, but it looks like your code gets the bit count wrong for large data sets, as you are not using a uint64_t, you are using an array of uint32_t's, and dropping a size_t (== uint32_t) in there. For memory based operations you will be fine for most of your life (I guess). For a very large file, you will likely give the wrong answer. M -- Mark Murray iumop ap!sdn w,I idlaH