This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] fix pre-/post- in-/decrement
On Wednesday, October 13, 2010 1:00:04 am Tom Tromey wrote:
> >>>>> "Ken" == Ken Werner <ken@linux.vnet.ibm.com> writes:
> Ken> I overlooked that in case of C++ the various assignment,
> Ken> pre-increment and pre-decrement operators return lvalues while they
> Ken> return non-lvalues for C.
>
> I still had this patch in my queue, but I wasn't sure if it was
> obsoleted by something else...
First, thank you for looking at this. In my opinion the patch is still
relevant. The goal is to add unop support for vector types. The initial patch
contained (beside its main purpose) code to prevent post in-/decrement
operators from returning lvalues. Joel suggested this should be treated as a
separate patch. This is how this patch was born. It helps GDB to be more
accurate when it comes to the result types of unary operations.
> While I don't really mind having language checks in the expression
> evaluator, it seems like this particular error condition is something
> that could be detected in the C parser.
Hmm interesting. I guess you are referring to c-exp.y as this generates the
expression parser for both languages C and C++. I don't see how to control the
type of the result of an operator there. I'm still quite new to the GDB
parsing internals and would appreciate any insights.
> Also, I think the C++ rule is more complicated. I did not look through
> the standard to find it, but g++ at least gives an error for a simple
> scalar "x++ = 5".
Yes, this behaviour seems correct to me and the patch ensures that a non-
lvalue is returned in case of UNOP_POSTINCREMENT and UNOP_POSTDECREMENT as C
and C++ do not differ here. For BINOP_ASSIGN, BINOP_ASSIGN_MODIFY,
UNOP_PREINCREMENT and UNOP_PREDECREMENT C returns non-lvalues while C++
returns lvalues. This is why the patch checks the language and calls
value_non_lval for languages other than C++. I think the relevant sections of
the C++ standard are these:
5.3.2 Increment and decrement [expr.pre.incr]:
"The result is the updated operand; it is an lvalue, [..]"
5.2.6 Increment and decrement [expr.post.incr]
"The result is an rvalue."
5.17 Assignment and compound assignment operators [expr.ass]
"[...] return an lvalue with the type and value of the left operand after the
assignment has taken
place."
So, this patch doesn't conflict with the g++ behaviour you are seeing.
Regards
Ken Werner