Re: signal handling issues

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.