Re: Yacc error recovery...

creedy@mitretek.org (Chris Reedy)
24 Oct 1996 22:38:41 -0400

          From comp.compilers

Related articles
Yacc error recovery... kaz@nt.com (1996-10-03)
Re: Yacc error recovery... miano@worldnet.att.net (1996-10-06)
Re: Yacc error recovery... itz@rahul.net (1996-10-12)
Re: Yacc error recovery... creedy@mitretek.org (1996-10-24)
| List of all articles for this month |
From: creedy@mitretek.org (Chris Reedy)
Newsgroups: comp.compilers
Date: 24 Oct 1996 22:38:41 -0400
Organization: Mitretek Systems
References: 96-10-011 96-10-036
Keywords: parse, yacc, errors

itz@rahul.net (Ian T Zimmerman) wrote:
> TOPLAS vol.17 No.4 (July 95) pp. 672 and forward describes adding a
> fully automated error method to Bison. The article together with
> relevant source code are available on
>
> http://www.cosc.canterbury.ac.nz/~bruce


How would the technique in the article handle the following (ANSI/C) error?


int a_function( int p1, foo p2, int p3) {
      /* something involving p1, p2, and p3 */
}


foo was supposed to be int but I mistyped (when it actually happened
to me it came out Int -- can you tell the difference on your display?
I couldn't). The compiler I was using at the time reduced foo as a
parameter name, produced the unhelpful error message "syntax error",
and discarded "p2, int p3". It then produced additional errors in the
body for unknown variables p2 and p3.


I read the article and it seemed to me that the article would produce
something similar to the above, since the error token is "p2" while
the actual error was in "foo". If I'm right, are there error recovery
techniques that will recover by recognizing that foo was supposed to
be a type name?


    Chris


Dr. Christopher L. Reedy, Mail Stop Z667
Mitretek Systems, 7525 Colshire Drive, McLean, VA 22102-7400
Email: creedy@mitretek.org Phone: (703) 610-1615 FAX: (703) 610-1603
--


Post a followup to this message

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