#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