Kevin Pilch-Bisson <[EMAIL PROTECTED]> writes: > WIFEXITED and WEXITSTATUS are not portable. Applications may need more detail > than simply whether it exited due to a signal or not. For example, subversion > has a pre-commit hook which prevents a commit if it returns non-zero. We need > to be able to determine the exact return value. It is also useful when we run > programs such as diff and patch, which return diagnostics via the exit code.
I think it was understood that they weren't portable (since apr_wait_t was exposed). I understand why you want a nice congealed exit code, but you can't have such a thing without telling the user what you got (well, since a segfault currently reports APR_CHILD_NOT_DONE I guess you have that, sort-of). I wish I knew the history of these APR interfaces, but I don't. Why do we bother to define apr_wait_t and thus expose these details to the APR user, for example? It would seem to me that more fields will be needed in the apr_proc_t and we might as well get rid of the apr_wait_t parameter, since you can't look at that portably without knowing how the process exited. New fields in apr_proc_t, filled in by apr_proc_wait() and apr_proc_wait_all_procs(): 1) apr_wait_t native_exit_status (on Unix, this is the complete encoded status) 2) some_enum exit_type (normal-termination, uncaught-signal, stop-signal, whatever else) 3) union { int signal; (a terminating signal or stopping signal) int exit_code; } exit_status; I included mention of stopping signals here. I must confess that I don't know why we care about stopped processes. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...