I'm having a problem with error handling in the C target. In a file with
multiple recognition failures on different lines, the second error is being
reported with the same line number and proximity token as the first.
I think I have tracked down the problem but it seems incomprehensible that such
a blatant problem would still be extant, so I'm wondering if I'm overlooking
something.
The first recognition error causes an exception object to be created and
recorded in recognizer->state->exception. However I cannot find anywhere where
exceptions are freed. That is, after the first exception,
recognizer->state->exception is never NULL; it continues to point to the first
exception indefinitely.
The second error is a token mismatch, which results in a call to
recoverFromMismatchedToken(), which does:
// Create an exception if we need one
if (recognizer->state->exception == NULL)
antlr3RecognitionExceptionNew(recognizer);
The predicate fails because the first exception is still there... so the
constructor is not called... so the fields pinpointing the error are not set...
so the second error is reported with the same source filename and line number
as the first.
I was able to fix this by overriding reportError(), adding code to call
freeEx() and set recognizer->state->error to NULL. But it seems like this would
be part of the standard library implementation -- or at least there would be
something to take care of this.
My apologies if this a known issue -- I searched the various FAQs/Wikis/groups
as best as I could.
Regards,
Alan Davis
Texas Instruments
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
"il-antlr-interest" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
