Sujet : Re: signal handling issues
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.unix.programmerDate : 30. Jan 2025, 20:44:45
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20250130113438.837@kylheku.com>
References : 1
User-Agent : slrn/pre1.0.4-9 (Linux)
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.
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca