re: Q: Error detection/recovery in LEX/YACC (Help) (Byron Darrah)
Tue, 21 Dec 1993 17:32:15 GMT

          From comp.compilers

Related articles
Q: Error detection/recovery in LEX/YACC (Help) (1993-12-17)
re: Q: Error detection/recovery in LEX/YACC (Help) (1993-12-21)
Re: Q: Error detection/recovery in LEX/YACC (Help) (1993-12-23)
Re: Q: Error detection/recovery in LEX/YACC (Help) (1994-01-18)
Re: Q: Error detection/recovery in LEX/YACC (Help) (1994-01-27)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Byron Darrah)
Keywords: lex, yacc, errors
Organization: Compilers Central
References: 93-12-081
Date: Tue, 21 Dec 1993 17:32:15 GMT

          Darryl Friesen writes:

>I need a little help with error detection/recovery/repair in either or
>both of LEX and YACC (a little snippet of code, even just a few
>productions, would be tremendously appreciated! :).

          Here is a yacc production that uses the special error symbol to trap
parsing errors in a semicolon-terminated statement (as in C):

Statement : Stmt semicolon_tok
        | error semicolon_tok

          Whenever yacc encounters a parsing error, it effectively backs up the
stack util it can match the input to an error production. When it matches
such input, a call to yyerror() is made. You can supply your own
yyerror() routine, which prints whatever error messages you like. When
yyerror() returns, parsing continues just as if Statement had been

          You need to select your error productions strategically, so that if a
syntax error is encountered, (1) the nonterminal that gets produced does
not affect other symbols in the production (in my example, producing an
error Statement consumes all input up to and including a semicolon, which
should mean that the next statement is ready to be parsed), and (2) Which
nonterminal to produce is not ambiguous.

> PS. Is it best to keep all (most) symbol table interactions
>(ie. lookup, insertions) in the scanner? I'm a little new
>to LEX/YACC in case you haven't noticed :)

This aspect of the design is really up to you. You should consider of
what kind of information the symbol table will make use, then figure out
where the bulk of that information fits into your program -- in the
scanner or in the parser?

          I hope this helps. I didn't see any other posted responses to the
question, so I hope this is not too redundant, even though the question
was posted 4 days ago. :)
Byron C. Darrah | bus. mail: attn: Byron C. Darrah, Mail Station: B223
PHONE: (714) 732-9381 | Hughes Aircraft Company, GSD.
FAX: (714) 732-1953 | 1901 W. Malvern Ave. | Fullerton, California, USA
                                            | 92634

Post a followup to this message

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