Re: [patch] fix pre-/post- in-/decrement

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Ken" == Ken Werner <ken@linux.vnet.ibm.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++.

Yeah.

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.

Tom