Date: Thu, 10 Mar 2005 09:01:22 +0000 From: Mark Murray <markm@FreeBSD.ORG> To: Colin Percival <cperciva@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 Message-ID: <200503100901.j2A91MeN081641@grovel.grondar.org> In-Reply-To: Your message of "Thu, 10 Mar 2005 00:38:08 PST." <42300770.7040409@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200503100901.j2A91MeN081641>