Sujet : Re: signal handling issues
De : cross (at) *nospam* spitfire.i.gajendra.net (Dan Cross)
Groupes : comp.unix.programmerDate : 30. Jan 2025, 23:51:36
Autres entêtes
Organisation : PANIX Public Access Internet and UNIX, NYC
Message-ID : <vngvpo$ba2$2@reader2.panix.com>
References : 1 2
User-Agent : trn 4.0-test77 (Sep 1, 2010)
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.
- Dan C.