If memory serves me right, Bruce Evans wrote: > On Fri, 6 Sep 2002, Bruce A. Mah wrote: > > > If memory serves me right, Poul-Henning Kamp wrote: > > > > > Good catch. > > > > > > I'm surprised the compiler doesn't whine. > > > > Thanks, and "me too". > > Warnings are mostly turned off for not unimportant places like libraries > since these places are too poorly written to compile without warnings.
Apparently. > > PS. Actually I'm surprised that nobody caught the problem in the past > > five months...this bug prevented release builds from 5-CURRENT hosts. > > Maybe I'm the only person crazy enough to try this. :-) > > This bug was caught in PR 42384. The fix in the PR is not so good. I suppose I didn't look hard enough when I scanned through the PR database. I'll deal with the PR. > libmd is also broken for some cases involving pipes. IIRC, this is > caused by the bogus st_size checks in the same function. st_size is > only valid for regular files. It's puzzling that the call to lseek(2) doesn't always return an error in these cases as well (as the manpage seems to imply). Yet, one can do md5(1) on a pipe: tomcat:bmah% cat /etc/motd | md5 9caae6eae6f9c2dfea77d6a5fae2e93c tomcat:bmah% md5 /etc/motd MD5 (/etc/motd) = 9caae6eae6f9c2dfea77d6a5fae2e93c > The loop in the function fails to to terminate if read() returns 0, > which can probably happen if the file shrinks underneath us. Maybe add a check after the read(2), so that if it returns zero, we set n = 0? It's not clear to me what result should be returned in the case of trying to compute a checksum on a file that shrinks in the middle of the computation. Thanks, Bruce.
msg42775/pgp00000.pgp
Description: PGP signature
