[commit-cp] [bug #12834] FileInputStream.read(...) broken when underlying read returns 0 bytes

[anonymous]

URL:
  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=12834>

                 Summary: FileInputStream.read(...) broken when underlying
read returns 0 bytes
                 Project: classpath
            Submitted by: None
            Submitted on: Wed 04/27/2005 at 19:06
                Category: classpath
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
        Platform Version: None

    _______________________________________________________

Details:

The current versions of FileInputStream.read(...) are broken in the following
respect.

For FileInputStream.read():  this function simply calls C read() once and
returns the results.  However if the C read() returned 0 bytes read, then bad
data is returned in Java.  This is incorrect, as FileInputStream.read()
guarantees that it either returns a byte read or an error.  Thus,
FileInputStream.read() should poll until C read() returns non-zero bytes
read.

For FileInputStream.read(buffer[], offset, length): this function has exactly
the opposite error.  Here the function blocks repeatedly until length bytes
are read or EOF occurs which is not the proper behavior.  If the stream for
some reason or another is constantly returning 0 bytes read -- as was the
case in an incorrectly-written /dev device we found recently --
FileInputStream.read(...) will go into an infinite loop.  Instead,
FileInputStream.read(...) should have some way of (validly) returning less
than length bytes if that was what was provided it by the underlying C read()
function.







    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=12834>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/