bisonc++ 0.98.510 buggy?

"Michael Brown" <michael@emboss.co.nz>
3 Jun 2006 18:57:16 -0400

          From comp.compilers

Related articles
bisonc++ 0.98.510 buggy? michael@emboss.co.nz (Michael Brown) (2006-06-03)
Re: bisonc++ 0.98.510 buggy? michael@emboss.co.nz (Michael Brown) (2006-06-05)
| List of all articles for this month |
From: "Michael Brown" <michael@emboss.co.nz>
Newsgroups: comp.compilers
Date: 3 Jun 2006 18:57:16 -0400
Organization: Compilers Central
Keywords: yacc, C++, question
Posted-Date: 03 Jun 2006 18:57:16 EDT

I'm trying to make a C++ parser for a configuration file, and starting to
get the feeling that it'd be easier to start again from scratch with a
hand-written lexer/parser ...


The bug I've run into is that the parser appears to be violating a rule of
the grammar. I have the following rules (among others):


IntFloatDim : IntFloat Identifier
    {
        $$ = new CParserIntFloatDim($1, $2);
    };


IntFloat : TOK_FLOAT
    {
        $$ = new CParserIntFloat(atof(d_scanner.YYText()));
    };


Identifier : TOK_IDENTIFIER
    {
        $$ = strdup(d_scanner.YYText());
    }


with TOK_FLOAT matching a floating point number string and TOK_IDENTIFIER
matching "[a-zA-Z][a-zA-Z0-9]*". The interesting part is that the Identifier
rule is not getting used, although it IS getting lexed. For example, on the
string "1.0 m", the IntFloat rule gets used, followed immediately by the
IntFloatDim rule, with garbage in the $2 value. However, the "m" token does
not cause problems in subsequent rules, so it's definately getting lexed.
It's just vanishing into thin air afterwards.


Also, is there any way to make bisonc++ insert things into the parser.h and
parserbase.h files? %{ ... %} has been removed, so I've resorted to applying
a patch to the generated files ... not the cleanest or most robust solution.
A pointer to bisonc++ documentation would also be appreciated. The only
documentation I can find is the "C++ annotations" thing which doesn't really
go into a lot of detail. The documentation that comes with bisonc++ is just
the stock bison documentation, which doesn't help at all when trying to work
around the differences in bisonc++.


Finally, are the any alternatives to bisonc++ that are in a better state?
I've tried bison++ but that produces parsers which as far as I can tell,
don't have a hope of compiling under any vaugely recent g++. All I want to
do is parse a fairly simple configuration file into a C++ object heirachy,
but I've spent about two weeks fighting various forms of lex and yacc/bison
and frankly am amazed that anyone manages to produce anything more complex
than a calculator with these tools.


--
Michael Brown
Add michael@ to emboss.co.nz ---+--- My inbox is always open


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.