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

[Ken Werner <ken@linux.vnet.ibm.com>]

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