[antlr-interest] problem in displayRecognitionError() in antlr2baserecognizer.c

[Xie, Linlin]

Hello Jim and all,

 

I wonder if there is any bug in antlr setting the "expecting" member
variable of struct "ANTLR3_EXCEPTION". The following is what I find out
while assigning my own error processing function to antlr's recognizer's
reportError function pointer:

 

For my grammar definition like:

"Query: Rule1 Rule2? Rule3? ; EOF"

And for my test case that has a malformed syntax, which matches Rule1,
but the rest doesn't match either Rule2 or Rule3, through debugging, I
find that the parser then tries to match with ";", of course it doesn't
match ";" again, then it tries to report error and recover. 

 

In the antlr's error reporting (I did it by copying the content of
displayRecognitionError() to my own error processing function), the
"expecting" variable should point to the position of ";" as that's what
it tries to match. But it shows that the expecting is a very large
number that can't possibly be within the range of the vector
"TokenNames", however as C doesn't have exception handlings, the print
out is "null", if without looking carefully, it seems to be no problem
at all. But what I'm trying to do in my own function is to read out the
error information from antlr exception and output it into standout
output in C++, that's how an exception is thrown in C++ that leads me to
the problem. I did some probing of the antlr code, and think it could be
a bug when antlr sets the "expecting" variable in case of such an error.
Also I find that the exception variable has a nextexception pointer
which points to another exception variable which has exactly the same
member variable values except the "expecting", this "expecting" indicate
the position of ";" token, so to me this nextexception variable should
be the one that should be error for this test case. 

 

Jim, could you treat it as a bug report and do some investigation on it?
Or can anybody figure out why it's working this way if it's not a
problem? Thank you very much.

Regards,

Linlin

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20090609/f058aa81/attachment.html