#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
---------------------------------+------------------------------------------
Comment(by nominolo):
The behaviour of `hGetBuf` probably shouldn't be changed. Changing the
behaviour of `hGet` to the documented behaviour might cause compatibility
problems as well. I would therefore prefer a new function with the
behaviour that `hGet`'s documentation currently describes and which
matches `Network.Socket.recv`. The straightforward implementation has a
few subtle preconditions, though:
{{{
hRecv :: Handle -> Int -> IO ByteString
hRecv h size = do
handle (\(e :: IOError) -> return S.empty) $ do
-- Note: hWaitForInput tries to decode its input, so we must make
-- sure the handle is in binary mode.
hWaitForInput h (-1)
hGetNonBlocking h size
}}}
I guess what's missing is a function similar to `hWaitForInput` that
ignores the decoding mode? Other possible names for this function that I
can think of are `hGetUpTo` or `hGetMax`.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4041#comment:2>
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
