help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Dealing with errors generated while lexing


From: Nikolai Weibull
Subject: Dealing with errors generated while lexing
Date: Thu, 6 Dec 2012 13:05:22 +0100

Hi!

Is there a simple way for yylex to tell the parser to YYABORT?

I’ve tried to figure out how to deal with errors generated while
lexing.  Say that I hit an out-of-memory condition while lexing and
want to abort the parse.  I see no easy, general way of reaching a
point where I can YYABORT.  It’s manageable for tokens that have a
value, as you can simply check for an error value, for example, NULL,
but I can’t seem to come up with a good solution for non-value tokens.
 I would like to be able to return an error token from yylex, but
there doesn’t seem to be any provisions for doing so.  I guess one
could return a token that’s not allowed anywhere, but that would
generate a syntax error, which isn’t the kind of handling that I want.
 One could further try to handle this error token, but then one would
have to add a rule for that case in a lot of places.  You could add a
value to the token as well and check for an error value, but it won’t
work for rules such as

a: TOKEN b;

as you won’t be able to check if TOKEN has the error value until b has
been seen and the action has been entered.

I was also thinking of using setjmp in an %initial-action and then
longjmping to it if an error occured and from there YYABORTing, but if
I understand my ISO C, yychar, yylen, and other auto variables that
the yyreturn code depends upon will have indeterminate values, meaning
that cleanup might not be performed correctly.  I noticed that the glr
parser uses this kind of code to get out of out-of-memory conditions,
but as far as I can tell, its code is similarly susceptible to using
indeterminate values for these variables.  Am I wrong?

Thanks!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]