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...
