I think I've found a bug in libmd on -CURRENT, in which attempting to compute the MD5 checksum (using MD5File(3)) of a zero-length file generates an error. A trivial way to trigger this bug (which isn't present in 4-STABLE) is:
ref4:bmah% uname -a
FreeBSD ref4.freebsd.org 4.7-PRERELEASE FreeBSD 4.7-PRERELEASE #8: Mon Sep 2 03:20:42
PDT 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/REF4 i386
ref4:bmah% ls -ls foo
0 -rw-r--r-- 1 bmah bmah 0 Sep 6 08:54 foo
ref4:bmah% md5 foo
MD5 (foo) = d41d8cd98f00b204e9800998ecf8427e
ref5:bmah% uname -a
FreeBSD ref5.freebsd.org 5.0-CURRENT FreeBSD 5.0-CURRENT #11: Mon Sep 2 03:30:53 PDT
2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/REF5 i386
ref5:bmah% ls -ls foo
0 -rw-r--r-- 1 bmah bmah 0 Sep 6 08:54 foo
ref5:bmah% md5 foo
md5: foo: Undefined error: 0
This bug seems to have been introduced in rev. 1.14 of src/lib/libmd/
mdXhl.c; the patch below (which makes sure a variable gets initialized
before first use, even in the case of a 0-length file) seems to fix it.
Comments?
Bruce.
PS. I found this because at some point during a release build, mtree(8)
tries to compute the MD5 checksum of a zero-length file, namely
/etc/dumpdates.
Index: mdXhl.c
===================================================================
RCS file: /usr/local/cvsroot/src/lib/libmd/mdXhl.c,v
retrieving revision 1.16
diff -u -r1.16 mdXhl.c
--- mdXhl.c 25 Mar 2002 13:50:40 -0000 1.16
+++ mdXhl.c 6 Sep 2002 16:02:52 -0000
@@ -66,6 +66,7 @@
len = stbuf.st_size - ofs;
if (lseek(f, ofs, SEEK_SET) < 0) return 0;
n = len;
+ i = 0;
while (n > 0) {
if (n > sizeof(buffer))
i = read(f, buffer, sizeof(buffer));
msg42674/pgp00000.pgp
Description: PGP signature
