[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
---------------------------------------------------------------------------