#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

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

Reply via email to