Re: Bison 1.50 breaks reentrant yyerror() usage

[Ralf S. Engelschall]

On Sat, Oct 12, 2002, address@hidden wrote:

> > I don't think so.  Apparently we need to rethink subroutines within
> > the parser; in the meantime the simplest fix is to undo the introduction
> > of yyreport_parse_error, so I've installed the following patch.
>
> Damn it!  I was really hoping nobody would be #defining yyerror :(
> This is soo bad, but soo mandated by the brokenness of the current inter-
> face :(
>
> I have long been thinking about this (I have exactly the same problem,
> and was also doing this attrocious thing, but I thought I was the only
> one...) and thing that what we want is:

You can be sure that currently (until better approaches exists) really
lots of people are redefining yyerror()... :-(

> %param {struct foo *my_foo} {my_foo}
> %param {char tab[10]}{tab}
>
> or some similar syntax.  This would completely replace *_PARAM which
> is very inconvenient (just look at the cascade of #-handling) and not
> portable to other languages.
>
> In addition, as demonstrated aove, one would have the possibility to
> have several parameters.  Since I am still thinking of introducing
> %include or %import some day, this increases the modularity.
>
> What do you people think?

Yes, an explicit functionality for defining the passed-through
parameter(s) would be the most clean solution. At least as long as those
parameter(s) Bison-internally are also passed-through so that they are
available even in error handling code, etc.

                                       Ralf S. Engelschall
                                       address@hidden
                                       www.engelschall.com