#4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure
-------------------------------+--------------------------------------------
Reporter: AntoineLatter | Owner: simonmar
Type: bug | Status: patch
Priority: high | Milestone: 7.8.1
Component: libraries/base | Version: 7.6.1
Resolution: | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime crash | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: | Related:
-------------------------------+--------------------------------------------
Comment(by simonmar):
In principle this is a good change, however I don't agree with the changes
in semantics of `hGetBufNonBlocking` and `hGetBufSome`. As it stands
right now, `hGetBuf`, `hGetBufNonBlocking` and `hGetBufSome` will all
read the same amount of data, if the data is available without blocking.
But in your version (unless I've misread it), `hGetBufNonBlocking` will
read at most a buffer of data, which seems to me to be an abstraction
violation - the buffer size is supposed to be invisible to callers of the
`hGetBuf` family.
Why make this change? It should be possible to loop and read more data in
the same way as `hGetBuf`.
The only other minor quibble I have with this patch is that the
documentation for `readBuffered` and friends could be improved - it isn't
clear what the purpose of the buffer argument is (without reading the
code).
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4144#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
