Bug in some textutils handling of fread()/EOF

[Michael Bacarella]

Hi,

How to reproduce:

    1. Run md5sum interactively.  Make sure you're using textutils
    md5sum, some GNU/Linux distributions (like Debian) have their own
    md5sum and rename the one from textutils to something like md5sum.textutils.
        $ md5sum
 
    2. Type one line of text into md5sum, then hit CR. "foobar" works.
        $ md5sum
        foobar

    3. Now hit EOF.  Nothing should happen (the bug)
        $ md5sum
        foobar

    4. Hit EOF again.  Now it should exit.
        $ md5sum
        foobar
        14758f1afd44c09b7992073ccf00b43d  -
        $

Doing this again under strace reveals:

    read(0, foobar
    "foobar\n", 4096)               = 7
    read(0, "", 3072)                       = 0
    read(0, "", 3072)                       = 0
    [..other stuff removed..]
    close(0)                                = 0

  that fread() ends up being called again, even though it has
already found EOF.  The bug in some textutils is that they are expecting
slightly different fread() libc semantics.

They are expecting fread() to return 0 when it reaches EOF.  Specifically
when fread() is used with size = 1, nmemb > 1.

This is untrue.  fread() can return non-zero but still report EOF.
The three attached patches save this unnecessary additional call
to fread() in cksum, md5sum and sha1sum.

There may be other instances, but these are the only ones that
have affected me. ;)

Thanks.

-- 
Michael Bacarella                  24/7 phone: 646 641-8662
Netgraft Corporation                   http://netgraft.com/
      "unique technologies to empower your business"

Finger email address for public key.  Key fingerprint:
  C40C CB1E D2F6 7628 6308  F554 7A68 A5CF 0BD8 C055

cksum.patch
Description: Text document

md5.patch
Description: Text document

sha.patch
Description: Text document