[vox-tech] how to get yacc/bison to say "i'm confused"
Jeff Newmiller
vox-tech@lists.lugod.org
Thu, 27 Dec 2001 13:14:18 -0800 (PST)
On Thu, 27 Dec 2001, Peter Jay Salzman wrote:
> begin Jeff Newmiller <jdnewmil@dcn.davis.ca.us>
> > On Thu, 27 Dec 2001, Peter Jay Salzman wrote:
> >
> > > newbie here.
> > >
> > > i'm using flex/bison for processing a program's user input, and have a
> > > list of rules that define the user input grammar.
> > >
> > > after bison processes all it's input, is there a way of telling it:
> > >
> > > if no rule matched the input, take your input and feed it to
> > > ParseError(const char *error)?
> > >
> > > the problem i'm having is typically:
> > >
> > > ruleset: TOK_RULESET NUMBER { ChangeRuleset($2); }
> > > | TOK_RULESET { ChangeRuleset(-1); }
> > >
> > > if the user types something like "ruleset asdf", it'll match
> > > "TOK_RULESET", and (i think) "asdf" gets put back into the buffer since
> > > it's not a NUMBER, and is processed the next time the user inputs
> > > something. in other words, bison gets out of sync and confused.
> >
> > I think your rules do not convey that you feel the "asdf" must be
> > associated with "ruleset" even though it isn't a number. Your definition
> > of "ruleset" says a bare "ruleset" token can be a valid ruleset, so
> > any non-number following it must be associated with another rule.
>
> i see what you mean, but i think bison knows the end of input since my
> input is coming from a const char * (as opposed to a file) and i used
> lex to define \n to return 0. i believe bison recognizes 0 to mean end
> of input.
Yes, bison recognizes 0 as end of input. I am not talking about end of
input... I am talking about defining what a whole "ruleset" command is.
ruleset: TOK_RULESET NUMBER EOC { ChangeRuleset($2); }
| TOK_RULESET EOC { ChangeRuleset(-1); }
where your lexical parser would identify the end of command as newline,
unexpected end of string (have it insert an EOC before returning the 0),
semicolon, or what have you.
> > I think you need to specify a terminal "end of arguments" token in your
> > syntax to identify "optional argument" behavior. This could be
> > end-of-line, or semicolon, or parentheses. Then, the "ruleset" rule
> > cannot match "ruleset asdf" because the end-of-arguments token will follow
> > the unrecognized "asdf".
>
> i managed to stumble across the fact that you can redefine yyerror(),
> which does exactly what i want it to. if bison can't parse an input
> correctly, it calls yyerror.
But without the end of command token, the "asdf" appears to stand on its
own as a command instead of as an invalid argument to the "ruleset"
command. The difference lies in the clarity of error reporting.
[...]
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<jdnewmil@dcn.davis.ca.us> Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...2k
---------------------------------------------------------------------------