This is the mail archive of the
mailing list for the GDB project.
Re: [patch] fix pre-/post- in-/decrement
>>>>> "Ken" == Ken Werner <email@example.com> writes:
Tom> While I don't really mind having language checks in the expression
Tom> evaluator, it seems like this particular error condition is something
Tom> that could be detected in the C parser.
Ken> Hmm interesting. I guess you are referring to c-exp.y as this
Ken> generates the expression parser for both languages C and C++.
Ken> I don't see how to control the type of the result of an operator
Ken> there. I'm still quite new to the GDB parsing internals and would
Ken> appreciate any insights.
It is probably a bit of a pain, since the IR generated by the parser is
a bit unusual (as compilers go).
However, it seems to me that it would be much friendlier for users to
report this as a parse error rather than a runtime error.
One option would be to write a C/C++ implementation of the language_defn
la_post_parser method, which would look at the expression to see if this
constraint is violated.
Another option would be to try to implement it in the grammar.
Tom> Also, I think the C++ rule is more complicated. I did not look through
Tom> the standard to find it, but g++ at least gives an error for a simple
Tom> scalar "x++ = 5".
Ken> Yes, this behaviour seems correct to me and the patch ensures that
Ken> a non- lvalue is returned in case of UNOP_POSTINCREMENT and
Ken> UNOP_POSTDECREMENT as C and C++ do not differ here.
Thanks for the correction and the links to the standard.