Re: [PATCH 1/2] setjmp: Use BSD sematic as default for setjmp

[Florian Weimer <fweimer@redhat.com>]

* Adhemerval Zanella Netto:

>> Ahh, you mean because use removed the signal unblocking from abort?
>> 
>> If the signal is blocked, it is not delivered before it is unblocked.
>> This means that the handler will not observe it blocked.
>> 
>> But POSIX says this:
>> 
>> | The abort() function shall override blocking or ignoring the SIGABRT
>> | signal.
>> 
>> It also says:
>> 
>> | The SIGABRT signal shall be sent to the calling process as if by means
>> | of raise() with the argument SIGABRT.
>> 
>> Strictly speaking, it is impossible to comply with both requirements,
>> but I think the handler is expected to run even if SIGABRT is blocked.
>> As far as I understand it, the new code terminates the process in this
>> case, without ever running the handler.
>
> The later has been changed with a new clarification [1]:
>
>   The SIGABRT signal shall be sent to the calling [CX]thread[/CX] as if by
>   means of raise() with the argument SIGABRT. [CX]If this signal does not 
>   terminate the process (for example, if the signal is caught and the handler 
>   returns), abort() may change the disposition of SIGABRT to SIG_DFL and send 
>   the signal (in the same way) again. If a second signal is sent and it does 
>   not terminate the process, the behavior is unspecified, except that the 
>   abort() call shall not return.[/CX]
>
> [1] https://austingroupbugs.net/view.php?id=906#c5851

Okay, I missed that change.  So removing the unblocking should be okay
after this specification change.  I still don't see how the removal of
unblocking changes the signal mask observed by the signal handler,
though.

Thanks,
Florian