Re: Bison GLR buffer-overflow and invalid pointer fixes

[Paul Hilfinger]

 > Paul Eggert wrote:
 > 
 > > Frank Heckenbach <address@hidden> 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.