Hi Eli,
Eli Zaretskii <e...@gnu.org> writes:
>> The Gnulib sys_wait module says in its comments:
>>
>> "When an unhandled fatal signal terminates a process,
>> the exit code is 3."
>>
>> If this is wrong, can you help me understand what they might have been
>> thinking when they wrote it?
>
> They were thinking about a single use case: a program that calls
> 'abort'. Such a program on Windows exits with a status code of 3.
>
> But that is not very interesting in the case in point, and besides,
> some programs exit with code 3 for other reasons. One such example is
> wget, and there are others.
>
> More to the point, when a Windows program is terminated with an
> unhandled fatal exception, it rarely if ever terminates via 'abort'.
Thanks for this explanation. You have convinced me that we should not
import the current 'sys_wait' or 'waitpid' Gnulib modules, and that we
should instead use something closer to what you wrote.
However, I don't want to use the "0xC0000200 + SIGNAL" convention
"between Guile and itself" that you've invented. Instead, based on what
you wrote, I guess that we should make WIFSIGNALED(x) return true for
any status code of the form 0xC0000xxx, or maybe some larger set. I
guess that WIFEXITED(x) should return the logical not of WIFSIGNALED(x).
WIFSTOPPED(x) presumably should always return false.
In the code you wrote:
> # define WIFEXITED(stat_val) (((stat_val) & 0xC0000000) == 0)
> # define WIFSIGNALED(stat_val) (((stat_val) & 0xC0000000) != 0)
WIFSIGNALED(x) returns true if either of two high bits are 1. This
seems a bit too loose to me. Would it be better to include more bits in
the mask, and to compare it with a specific value instead of simply
checking that at least one of those high bits is 1?
> # define WTERMSIG(stat_val) ((stat_val > 0xC0000200) ? stat_val -
> 0xC0000200 : stat_val)
I'd prefer to define WTERMSIG differently that this, which would return
very large values like 0xC0000005 for the Windows equivalent of SIGSEGV.
I think we should try to translate these until something that will make
more sense to a program written for POSIX.
IMO, it would be reasonable to just return SIGTERM in all cases, like
Gnulib does, but perhaps we should map some known values to specific
signals. You mentioned that the equivalent of SIGSEGV on Windows
results in a 0xC0000005 status code. Any others worth mapping?
What do you think?
I will respond to the other subthreads at a later date.
Thanks,
Mark
