> Paul Eggert wrote: > > > Frank Heckenbach <[EMAIL PROTECTED]> writes: > > > > > one could of course always #define them to setjmp/longjmp, I > > > suppose. > > > > Yes, that's true, but the tricky part is how to determine whether > > they're available, without imposing on the user's name space or > > requiring Autoconf. In other areas like this, glr.c's method has > > always been to assume the latest system, so there is some precedent > > for simply using sigsetjmp. > > I meant user code that doesn't want to assume the latest system > could do so, probably using autoconf itself.
Thinking about this, I realized that we've overlooked a constraint: bison is in the business of producing C (C++, etc.) programs, *NOT* C programs for a particular architecture. There are numerous instances of implementors using Bison (or Yacc) to create parts of a distribution that will go out to multiple architectures. Therefore, an autoconf-based solution is inappropriate. The user who plays around with the signal mask is just going to have to be aware of the issue. The appropriate course, I think, is 1. Replace the calls with macros e.g., YYSETJMP, YYLONGJMP. 2. Define these macros to leave the signal mask untouched on Posix-compliant systems and (if there is a reliable BSD-detecting macro symbol) BSD, if the user doesn't define them. 3. Document this. Paul H.
