[PATCH 1/2] setjmp: Use BSD sematic as default for setjmp
Florian Weimer
fweimer@redhat.com
Wed Aug 2 14:43:23 GMT 2023
* 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
More information about the Libc-alpha
mailing list