cvs commit: src/lib/libmd Makefile sha256.3 sha256.h sha256c.c shadriver.c src/sbin/md5 Makefile md5.c

[Peter Jeremy]

On Wed, 2005-Mar-09 12:00:06 -0800, Colin Percival wrote:
>it.  As for md5 and sha1, it's useful to have a minimalist libmd for
>applications which don't require the bloated monst^W^W^W OpenSSL, and
>these are small enough that a bit of duplication really doesn't matter.

The problem isn't the bloat, it's the maintenance effort.  Three almost,
but not totally, identical versions of foo() means three times as much
maintenance effort and a non-zero probability of someone forgetting
to make a change to one of the versions.

>Assembly optimization might be worthwhile; but for this sort of code, I
>think you'd need to have a version optimized for each *processor* rather
>than each *platform* in order to get any significant gain.

Not necessarily.  MD5 and SHA-x both use operations (like rotate) that
are primitives in at least some of the CPUs that we support but not in
C.  Model-specific code would be nicer - and having only one copy of
the relevant functions would make it a lot easier to support lots of
different code variants.  (Of course, it would be nice if FreeBSD
included the hooks to support model-specific code ala Solaris).

>  These hash
>functions are designed for 32-bit processors in a manner which makes it
>fairly hard for the compiler to get things wrong.

It's not so much getting things wrong as being able to get the right
answer quicker.  It may not be obvious to the compiler that
	a = (a << 5) | (a >> 27);
can be replaced by
	rotl	a,5
and someone with a suffiently warped point of view is likely to manage
to find novel ways to express the algorithm that the compiler would
never think of.

-- 
Peter Jeremy