#4041: possible misbehaviour of hGet/hGetBuf
---------------------------------+------------------------------------------
Reporter: duncan | Owner:
Type: bug | Status: new
Priority: normal | Component: libraries/base
Version: 6.12.1 | Keywords:
Os: MacOS X | Testcase:
Architecture: Unknown/Multiple | Failure: Incorrect result at runtime
---------------------------------+------------------------------------------
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 <[email protected]>
* 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).
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4041>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
