[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bison GLR buffer-overflow and invalid pointer fixes
From: |
Paul Hilfinger |
Subject: |
Re: Bison GLR buffer-overflow and invalid pointer fixes |
Date: |
Fri, 08 Jul 2005 15:35:36 -0700 |
> 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.
Message not available