Re: Parser error handling

haberg@matematik.su.se (Hans Aberg)
23 Aug 2003 23:10:25 -0400

          From comp.compilers

Related articles
Parser error handling piotr.wyderskiREMOVE@hoga.pl (Piotr Wyderski) (2003-08-20)
Re: Parser error handling haberg@matematik.su.se (2003-08-23)
Re: Parser error handling piotr.wyderskiREMOVE@hoga.pl (Piotr Wyderski) (2003-08-30)
Re: Parser error handling haberg@matematik.su.se (2003-09-04)
| List of all articles for this month |

From: haberg@matematik.su.se (Hans Aberg)
Newsgroups: comp.compilers
Date: 23 Aug 2003 23:10:25 -0400
Organization: Mathematics
References: 03-08-059
Keywords: parse, errors
Posted-Date: 23 Aug 2003 23:10:25 EDT

  "Piotr Wyderski" <piotr.wyderskiREMOVE@hoga.pl> wrote:


>I'm writing a translator for an experimental language using Bison and
>Flex.
...
>One of my problems is to report a lexical error and stop the parser
>immediately after that.
..
>So, my first question is how to report lexical
>errors and stop parsing correctly.


Depends on what you mean by "stop parsing correctly". You could for
example let the lexer write out an error message, and then return a
token to the parser which is not used anywhere, which will cause it to
generate an error.


I think that is about how good the Flex/Bison error handshaking is
right now, but that improvements is on the todo list.


If one wants any outstanding reductions to first be executed I
recently made a suggestion to the Bug-Bison list, in the thread
"Featuritis: Token actions": Tokens with actions attached to them
which would be executed when it is time to shift the next token. This
seems to be right for debugging tokens. There remains only somebody
willing to implement it in to Bison. :-)


>The second question is about cleaning the intermediate results during
>failures. The parsing tree is composed of objects derived from the
>Node class; the parser's stack stores pointers to that
>objects. Provided semantic actions use that pointers as parameters,
>create and initialize a new node using them and put it onto the stack
>-- nothing unusual. When there's an error, the stack may contain
>pointers to "intermediate" nodes. They should be deleted to prevent
>memory leakage. How to assure that those objects will be destroyed?


I assume you are using C as output language. I use C++, where I write
user classes which the C++ language can clean up.


For C, Akim Demaille has implemented a %destructor feature. See for
example the thread "Destructor trouble" in May in the Help-Bison
list. I do not know exactly how it works, as I am only using C++ where
it is not needed, but it should be called when there is an error and
the stack needs to be unwinded. In other cases (non-error), you will
have to do the cleanup via the parser actions.


>Could you please show me a good flex/bison translator (i.e. its source
>code) with correctly solved error reporting? I'd like to see a good
>example of ER and finish my own translator. Thanks in advance.


You can always ask in the Flex and Bison lists:
    Help-flex mailing list
    help-flex@gnu.org
    http://mail.gnu.org/mailman/listinfo/help-flex


    help-bison@gnu.org http://mail.gnu.org/mailman/listinfo/help-bison
    bug-bison@gnu.org http://mail.gnu.org/mailman/listinfo/bug-bison


    Hans Aberg * Anti-spam: remove "remove." from email address.
                                    * Email: Hans Aberg <remove.haberg@member.ams.org>
                                    * Home Page: <http://www.math.su.se/~haberg/>
                                    * AMS member listing: <http://www.ams.org/cml/>


Post a followup to this message

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