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

#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
participants (1)
-
GHC