#3341: encoding errors could be handled better
-------------------------------+--------------------------------------------
Reporter: judahj | Owner:
Type: bug | Status: new
Priority: high | Milestone: 6.12.1
Component: libraries/base | Version: 6.11
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: MacOS X
Architecture: x86 |
-------------------------------+--------------------------------------------
Comment (by simonmar):
Replying to [comment:3 judahj]:
> However, from a UI perspective it seems to me that when `NoBuffering` is
set we should not be pausing to wait for more input. Instead, when a
partial byte sequence is read but `hReady` is false we should raise an
error. (This is the current behavior of Haskeline.) Thus, when a user
has the wrong LANG set and types a character they will immediately get
feedback that something's off.
That's an interesting idea. Is there a precedent for it? Are you sure
that it isn't possible to get buffering issues, for instance if you're
typing over an SSH connection, might a byte sequence happen to be broken
into separate network packets?
FYI, the buffering mode make no difference for input handles in GHC. We
always use a buffer, but it is invisible to the client. This is because
we always allow the client to read whatever data is available; the input
functions never block if there are any characters to return, except in the
case of `hGetLine` which waits for a newline.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3341#comment:4>
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
