Re: Bison version 1.875e available for testing

[Kelly Leahy]

> Perhaps I've misunderstood what you mean by
> `%parse-param', and I haven't
> looked it up.  I generate a reentrant parser and
> make use of the ability
> to pass an object by means of a `void*' to
> `yyparse()'.  I use a unique
> object for each call to `yyparse()' so I can use the
> data members of that
> object in lieu of local automatic variables in
> `yyparse()'.
> 

I recommend you look it up.  It will solve your
problem, though it may not be the prettiest of
solutions.

> 
> >  > For non-threaded applications it would suffice
> to use static
> >  > variables local to the compilation unit for
> `yyparse()', but this
> >  > won't work with threads.
> >
> > Why is that?  It is up to you to pass to yyparse
> references to
> > automatic variables from its caller.  So I fail to
> see what actual
> > difference it would make.
> >
> 
> Because if they're static, there will only be one
> for all instances of
> `yyparse()' instead of a separate one for each
> instance.  I don't
> understand what you mean by passing references to
> automatic variables to
> `yyparse()' from its caller.  What I'd like are
> automatic variables local
> to `yyparse()', which cannot be referenced from
> outside `yyparse()'.
> 
> Laurence
> 

I'm not sure what he meant there either.  I think he
might have misread your post.

That being said, you can make your own function, say
"myparse()" that you call instead of yyparse() and
define it as follows:

int myparse() {
  localtype local1;
  localtype local2;

  return yyparse(&local1, &local2);
}

then use %parse-param to add these parameters to the
yyparse specification, and voila - pseudo-locals! 
These would still be hidden from the "outside world"
but would look local in parse-param for all intents
and purposes.

I suppose that if you were using a compiler that
supports references (not sure if this is only C++ or
C89 / C99), you could use reference parameters to make
them look even more like local variables in yyparse.

Kelly