[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.8.1
       Component:  libraries/process  |          Version:
      Resolution:                     |         Keywords:
Operating System:  Unknown/Multiple   |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown       |       Difficulty:  Unknown
       Test Case:                     |       Blocked By:
        Blocking:                     |  Related Tickets:
--------------------------------------+------------------------------------

Comment (by duncan):

 So on reflection, I think I'm changing my opinion.

 The H2010 docs say: "The exact interpretation of the code is operating-
 system dependent."

 So on that principle then I think we're well justified to use a reasonable
 encoding. This also means we don't have the trouble of braking existing
 code by adding a new `ExitCode` constructor. Existing code that doesn't
 interpret the exit code much will continue to work.

 As for the specific encoding. It would be madness for us to use the low
 bits for the signal. There must be plenty of code out there that looks for
 `ExitFailure 1` or other low numbers for example. So we would have to use
 Simon's encoding, high bits for a signal, low bits for a normal exit.

 I suggest we update the `ExitCode` docs to indicate how the `Int`
 corresponds to the system exit code on Windows and Unix (ie directly for
 Windows and the high 8 signal & low 8 normal exit code encoding for Unix).

 hvr raises a related question:

  * What should we do for `exitWith (ExitFailure n)` for `n > 255` on Unix?

 Currently the code just takes the low 8 bits. This is clearly silly since
 it would end up being equiv to `exitWith ExitSuccess`. Using numbers > 255
 is fine on Windows.

 In addition, if we are going to use 16 bits for the exit code on Unix then
 we ought to be able to use `exitWith` on such values.

 So, how about this for a specific suggestion:

  * On unix, use 16bits of the `ExitFailure Int`, high 8 for signal, low 8
 for normal exit code.
  * `waitForProcess` & `getProcessExitCode` return this encoding on Unix.
  * It is valid to `exitWith` an `ExitCode` from `waitForProcess` &
 `getProcessExitCode` and the top level handler should make this have the
 appropriate behaviour:
    * calling exit(n); or
    * calling kill(getpid(), s);
  * These are mutually exclusive. That is, we either get non-0 high byte or
 non-0 low byte but never both.
    * We enforce this on the `exitWith` side. An invalid encoding is
 replaced with `ExitFailure 255`. So that's used if both exit code + signal
 are set, or if it's > 16bit, or negative. But we do not make it an error
 because we don't want to create needless portability problems for programs
 using high Windows error codes.

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