Path: ...!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Rainer Weikusat <rweikusat@talktalk.net>
Newsgroups: comp.unix.programmer
Subject: Re: signal handling issues
Date: Fri, 31 Jan 2025 11:44:07 +0000
Lines: 40
Message-ID: <87h65f6we0.fsf@doppelsaurus.mobileactivedefense.com>
References: <874j1g18x2.fsf@doppelsaurus.mobileactivedefense.com>
	<20250130113438.837@kylheku.com> <vngvpo$ba2$2@reader2.panix.com>
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: individual.net lor+8UTOML0Oovklo/PQyg7pMuZR+UjINfkNqSE9gelqbzjTA=
Cancel-Lock: sha1:f7gt3Lsjjesd3N9lv5D7vPqtpkc= sha1:UMNymGdV2Gzc+KkCw4rmVJAqVzU= sha256:z5GD2C3vAyuL6qNP1BiIfSJ/tntdUo/cLD4CJGCq9Vo=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Bytes: 2820

cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <20250130113438.837@kylheku.com>,
> Kaz Kylheku  <643-408-1753@kylheku.com> wrote:
>>On 2025-01-30, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>> despite the statement from version 6 was retained as is. These two
>>> requirements seem to contradict each other. It would also be
>>
>>The older requirement can be interpreted as saying that if a signal goes
>>off, and the only functions in the interrupted call stack are async-safe
>>functions, then the handler may call async-unsafe functions.
>>This situation is outside of the conditions for undefined behavior
>>given in that requirement (handler calling unsafe, while interrupting
>>unsafe).
>>
>>The newer requirement seems to say that if an asynchronous signal goes
>>off, the handler may not call async-unsafe functions, regardless of what
>>is in the call stack. Even if no POSIX function at all has been
>>interrupted (only the application's own code), the behavior is undefined
>>if an unsafe function is called.
>>
>>So yes, these requirements conflict.
>>
>>> [I think this should be reported as a defect but there doesn't seem to
>>> be a way to do that or at least no obvious way.]
>>
>>Austin Group mailing list or whatever.
>
> Austin group has a defect tracker; one must be subscribed to the
> mailing list to submit an issue.
>
> I don't think this is a defect.

Mandating that functions defined by the standard behave as documented
when either called by a signal handler or interrupted by a signal unless
the signal handler interrupted an unsafe function and calls an unsafe
function while declaring that the behaviour is undefined if the signal
actually calls an unsafe function at least doesn't make any sense: How's
an unsafe function supposed to behave as documentend when called by a
signal handler if the behaviour is undefined when a signal handler
actually calls such a function?