Path: ...!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.unix.programmer
Subject: Re: signal handling issues
Date: Fri, 31 Jan 2025 13:12:08 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vnii77$css$1@reader2.panix.com>
References: <874j1g18x2.fsf@doppelsaurus.mobileactivedefense.com> <20250130113438.837@kylheku.com> <vngvpo$ba2$2@reader2.panix.com> <87h65f6we0.fsf@doppelsaurus.mobileactivedefense.com>
Injection-Date: Fri, 31 Jan 2025 13:12:08 -0000 (UTC)
Injection-Info: reader2.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="13212"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 4083
Lines: 68

In article <87h65f6we0.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat  <rweikusat@talktalk.net> wrote:
>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?

That is confusing.

I believe the intent is to say that it is undefined when a
signal-catching function causes an unsafe function to be called
in the context they describe, even if that function is not
directly invoked from the signal handler.  E.g., if one calls
`longjmp` or `siglongjmp` from the the handler, and then
whatever one jumps to calls an unsafe function such as `puts`.

One will note that there is some weasel language in issue 6
along these lines.  For instance, this paragraph:

|When signal-catching functions are invoked asynchronously with
|process execution, the behavior of some of the functions
|defined by this volume of IEEE Std 1003.1-2001 is unspecified
|if they are called from a signal-catching function.

Seems self-contradictory in much the same way you are saying
about the language in later issues.

POSIX has always tried to thread a very thin needle here, and I
do agree the language should be tightened up.  Filing a report
on the Austin Group issue tracker is the way to do so.

	- Dan C.