Re: yyerrok is missing in C++ parser

[Laurence Finston]

On Mon, 11 Aug 2008, kogorman wrote:

> Laurence Finston wrote:
> 
> Nope,  I grep for yyerrok on all files in the directory, and see only my own
> code and
> things directly generated from it.  I do not see a #define or other
> definiton.

> Did you do this from the code I included, or some of your own?  If the
> latter, I wonder
> what's different.  On that note, my Bison is version 2.3, as distributed
> with gentoo
> Linux.  What's yours?

It did occur to me that what I wrote was potentially misleading.  I didn't 
use your code (I seldom go that far) and my output file is only C++ code 
by virtue of my using C++ code in the actions.  Otherwise, it's a C 
parser.

> Yes, it's a matter of taste.  Partly.  But consider: that does not change
> the
> fact that if everyone acted as you do there would be no need for a C++
> version of Bison.  

I don't believe that there is a _need_ for one, but I have nothing to do 
with the Bison project except as a user and a (fairly) frequent poster to 
this list.  To the best of my knowledge, there's never a need for a C++ 
API for any library or utility such as Bison, since a C API can be used 
with C++ code.  If one uses, say, pthreads or sockets, one will have to 
use C (as opposed to C++), anyway. 

When I started using Bison, there was some reason why I didn't have it
generate C++ code.  Perhaps it was non-reentrant, but I don't really
remember. 

> Maybe that would be a good thing.  Maybe not.  But it's
> out here, and I'm trying it and it's not working for me.  The mailing list
> seems like the first step to take before filing a bug.  I like to do what
> footwork I can for the developers.

Just guessing now:  I would try grepping with the `-i' option or
grepping for `YYERROK'.  Or perhaps it needs to be qualified somehow
when generating a C++ parser.  Have you checked the skeleton file?
If you can't find anything, you might as well just ask on the
`bug-bison' mailing list.  There's no guarantee that you'll reach any
of the developers or the maintainer on this list.

> Of course, I'll try just fudging in the #define you gave above, and see if
> that works. 

If it's really a bug, I'm sure the maintainer will fix it.

> If not, since activity is low here, and there's only one
> respondent, I may well go back to a C version, but it seems a pity to me.
> For the courses, I'll likely use yacc and lex/flex on a C project to avoid
> the issue completely.

To the best of my knowledge, `yacc' is non-reentrant, so I would only
use it under exceptional circumstances.  I believe both Bison and Flex
have more features and options than `yacc' and `lex'.

Free Software is almost always developed by people who don't get paid
for their work and unless they find them themselves, they can only fix
bugs if people tell them about them.  The Bison developers have always
been very responsive to bug reports.

Laurence