[GHC] #11180: A program writing to a read-only stdout should not succeed
GHC
ghc-devs at haskell.org
Tue Dec 8 21:37:21 UTC 2015
#11180: A program writing to a read-only stdout should not succeed
-------------------------------------+-------------------------------------
Reporter: thomie | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.10.2
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by rwbarton):
It does fail if you add a `hFlush stdout` after the `print`.
After `main` finishes, apparently control somehow reaches `hs_exit()`,
which calls `flushStdHandles()` which in turn calls the Haskell function
`flushStdHandles` defined as
{{{
-- try to flush stdout/stderr, but don't worry if we fail
-- (these handles might have errors, and we don't want to go into
-- an infinite loop).
flushStdHandles :: IO ()
flushStdHandles = do
hFlush stdout `catchAny` \_ -> return ()
hFlush stderr `catchAny` \_ -> return ()
}}}
So, it's apparently intentional.
I agree this is poor, though. Maybe we should swallow exceptions when
flushing stderr, but not stdout? Or at least have the exception handler
cause the program to exit with a different status code (if that's still
possible at this point)?
For what it's worth gcc does the same thing as ghc currently does (the
error status of the `fflush` that happens after `main` finishes is
apparently not checked).
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11180#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list