Re: Fix signal handler

[Markus Elfring <Markus.Elfring@web.de>]

>
> I think it is simply impractical.

I have got the opposite opinion.


> It's not that we're ignoring a specification, it's that there _isn't_
> a concrete specification for the set of systems we're interested in.
>   

I have got doubts on your view. Known specifications are available for
POSIX and corresponding programming languages like C and C++. I know
that they have got open issues on their own because a few important
wordings are not as precise and clear as you might prefer.

For which software environments do you miss programming standards?

How many efforts would you like to spend on conditional compilation for
"special" platforms?


>
> But if you are interested in addressing the situation, I am suggesting
> that the first step would be to demonstrate that there in fact _is_ a
> race condition, and it is not simply some theoretical problem.
>   

I try to point out this open issue once more.

Can you imagine any unwanted results if the desired address can not be
atomically set in a way that fulfils requirements for signal handler
implementations?
Can it happen that the assigned function pointer will become a dangling
pointer because of word-tearing?


Another "dangerous" use case:
Do you know if any function is called during the execution in a signal
handling context that is not async-signal-safe like "fprintf()"?

Regards,
Markus