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
Simon Marlow recently added this documentation to
-- 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 <firstname.lastname@example.org> * 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).