On 21 Sep 2005, at 20:43, Paul Eggert wrote:
The C++ standard, 18.7:5, says:
I'm afraid that doesn't resolve the issue well enough for Bison. A
portable ISO C signal handler can't do much of anything -- all it can
do is set a global variable. Most real-world signal handlers in
Bison-using programs do more than that (e.g., longjmp, remove files,
etc.) but they are relying on POSIX guarantees not merely ISO C
guarantees.
POSIX allows portable signal handlers to do much of the stuff that
real-world signal handlers need to do, but POSIX does not specify how
C++ programs behave, and C++ does not specify how POSIX signal
handling works.
To me it looked as though signal handling must happen within the POF
C-like code, in order to fall within the C++ standard. In the case of
Bison, this means that if signal handling takes places within the
actions, and one wants to jump out of them, they must be first
converted to C++ exceptions, if the standard C++ parser is used,
i.e., the one using C++ containers. Alternatively, if conversions to C
++ exceptions cannot be done, one can use a compile C as C++ parser,
even though it won't be able to do cleanup in that case either. But,
at least, the behavior then is not undefined.
So there's no standard for how C++ exception handling
interacts with POSIX signals, and in practice I suspect it tends to be
a wild and woolly area.
The C++ standard says mixing a thrown exception with longjmp results
in undefined behavior. The situation is quite simple: both exists
within C++, but one must make sure signal handling and longjmp is
isolated within the C-like POF C++ subset.
Hans Aberg
