possible misbehaviour of hGet/hGetBuf

nominolo reports that the ByteString.hGet does not have the behaviour it is documented to have. ByteString.hGet is implemented almost directly in terms of System.IO.hGetBuf.

Simon Marlow recently added this documentation to ByteString.hGet:

-- If there is any data to read, then 'hGet' will not block, instead
-- it will return whatever data is available without blocking.  It
-- only blocks if there is no data available to read.

nominolo reports that with ghc-6.12.1 on OSX SL, that the actual behaviour is that hGet blocks until all the requested data is available, that is, it does not return a short read.

Simon clearly thinks that the documented behaviour of hGet is what the behaviour ought to be. In a previous patch to the ByteString package he writes:

Mon Mar 22 15:39:14 GMT 2010  Simon Marlow <marlowsd@gmail.com>
  * hGetContents: use hGet instead of hGetNonBlocking + hWaitForInput + hIsEOF
  
  Not only is this cleaner, but it fixes a problem with read binary data
  over a pipe, see
    http://hackage.haskell.org/trac/ghc/ticket/3808
  
  The problem is that bytestring normally works fine when the Handle is
  not in binary mode, because it uses hGetBuf/hPutBuf which bypass the
  encoding layer.  That is, except in this one particular case:
  hWaitForInput might do some decoding, because it has to determine
  whether there are any characters (not bytes) available to be read.
  
  I imagine hGetNonBlocking was used due to concerns that hGet might
  block if there is insufficient data, but that's not the case; hGet
  returns a short read if it would otherwise block, and only blocks if
  there is no data to read.

So it's not entirely clear what is going on. It's either confusion or a bug (possibly a system-dependent one).

Trac metadata

Trac field	Value
Version	6.12.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	libraries/base
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture