[GHC] #7229: Detecting if a process was killed by a signal is impossible

[GHC]

#7229: Detecting if a process was killed by a signal is impossible
----------------------------------+-----------------------------------------
    Reporter:  benmachine         |       Owner:                  
        Type:  bug                |      Status:  new             
    Priority:  high               |   Milestone:  7.6.2           
   Component:  libraries/process  |     Version:                  
    Keywords:                     |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple   |     Failure:  None/Unknown    
  Difficulty:  Unknown            |    Testcase:                  
   Blockedby:                     |    Blocking:                  
     Related:                     |  
----------------------------------+-----------------------------------------

Comment(by andersk):

 While that’s a small improvement over the previous undocumented behavior,
 it’s still not a real solution.  In Unix programming, it’s important to be
 able to reliably distinguish between `WIFEXITED(status)` (e.g.
 `exit(130)`) and `WIFSIGNALED(status)` (e.g. `raise(SIGINT)`), so that one
 can implement WCE (wait and cooperative exit) on `SIGINT`.  The 128 +
 signal thing that you see in your shell is specific to your shell; real
 languages do make this distinction.

 Really the right answer is to add a constructor to `ExitCode`.  While
 we’re doing that, we should expose `WCOREDUMP(status)` for completeness:
 `ExitSignaled {exitSignal :: Int, exitCoreDump :: Bool}`.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7229#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler