Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Re: YACC error handling heirich@cs.ucsd.edu (1989-07-29) |
| yacc error handling ajayk@microsoft.com (Ajay Kalhan) (1999-11-19) |
| Re: yacc error handling ajayk@microsoft.com (Ajay Kalhan) (1999-11-21) |
| Re: yacc error handling ewbank@lucent.com (Bryan Ewbank) (1999-11-23) |
| Re: yacc error handling zalman@netcom11.netcom.com (Zalman Stern) (1999-11-28) |
| Re: yacc error handling mschweis@u.arizona.edu (Michael C Schweisguth) (1999-12-07) |
| Re: yacc error handling wfahle@bigfoot.com (Bill Fahle) (1999-12-24) |
| From: | Zalman Stern <zalman@netcom11.netcom.com> |
| Newsgroups: | comp.compilers |
| Date: | 28 Nov 1999 01:37:52 -0500 |
| Organization: | MindSpring Enterprises |
| References: | 99-11-117 99-11-128 99-11-134 |
| Keywords: | parse, practice |
Bryan Ewbank <ewbank@lucent.com> wrote:
: Since there are parse errors, isn't the program going to exit? If so,
: why bother cleaning up?
This is precisely the attitude that makes makes compiler generation
tools (e.g. original lex/yacc) such a pain to use in areas other than
traditional batch compiler type applications. E.g. I want to specify a
network protocol using a parser generator because its a powerful tool
for doing so. But I cannot use such a tool if it results in an
implementation where the first erroneous packet that comes in causes
the protocol to wedge, leak memory, or even just causes an
unrecoverable error.
Fortunately, there are a number of parser generators that do
better. The many modified versions of yacc, Antlr, etc.
-Z-
Return to the
comp.compilers page.
Search the
comp.compilers archives again.