[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 hvr):

 Replying to [comment:7 andersk]:
 > that’s going to confuse anyone who knows that the real encoding is
 `(exit code << 8) + signal` (which, say, Perl forces you to learn).

 btw, what do you mean by //real// encoding?

 I've looked a bit around and here's what I've found so far:

 Python's [http://docs.python.org/3/library/os#os.wait os.wait()] operation
 which seem to match Perl's encoding:

     //... exit status indication: a 16-bit number, whose low byte is the
 signal number that killed the process, and whose high byte is the exit
 status (if the signal number is zero); the high bit of the low byte is set
 if a core file was produced.//

 ...otoh, Wikipedia says regarding
 [http://en.wikipedia.org/wiki/Exit_status#POSIX POSIX Exit status]:

     //... SUS specifies that the low-order 8 bits of the status value
 contain the exit status ...//

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