This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Volatile MEMs in statement expressions and functions inlined as trees



On 13 Dec 2001, Gabriel Dos Reis wrote:
>
> That quote is incomplete.  The above bullet goes on saying:
>
>    "the result is an lvalue."

You're right, I quoted a quote earlier in the discussion where that part
had already been dropped.

I kind of see your point, yet I still disagree. And I think the difference
in opinion is due to you seeing the expression "p = 0" to _degenerate_
into just plain "p" after the assignment, while I do not.

The "assignment" is still an entity in its own right, _independent_ of
"p".

Read on. Maybe we can at least resolve the _reason_ we disagree.

> That can't be since it in direct conflict with the rest of the
> sentence (5.17/1) which I reproduce for completeness:
>
>    There are several assignment operators, all of which group
>    right-to-left. All require a modifiable lvalue as their left operand,
>    and the type of an assignment expression is that of its left
>    operand. The result of the assignment operation is the value stored in
>    the left operand after the assignment has taken place; the result is
>    an lvalue.

Think of it this way: the text actually breaks up the status of
the assignment expression into three parts:

 - the _type_ of the assignment.

	Nobody has any quarrells here. Everybody agrees that the text is
	unambiguous, and that the type is the same as the type of the left
	side. From a type standpoint, the expressions "p = 0" and "p" are
	100% the same, so we get no disagreement.

 - the _value_ of the assignment expression, ie the value it returns

	Here, we get to the real crux of the matter. _I_ claim that the
	assignment expression "p = 0" has an intrisic value, the same way
	all expressions have, and that the standard claims that that
	intrisic value is the "value stored".

	You, on the other hand, claim that "p = 0" _degenerates_ into "p"
	itself, and that it does not have any intrisic value in itself,
	but that the expression is equivalent to just "p" _after_ the
	assignment.

 - the fact that the expression is a lvalue

	You take this to prove your "degenerate" point: "p = 0"
	_becomes_ "p" after the assignment.

	I, on the other hand, consider an "lvalue" to be nothing but the
	_address_ of the expression, and that "being an lvalue" only means
	that you can take its address.

	The fact that you can take its address is obviously where all the
	other attributes of "lvalues" come from - without an address you
	cannot store to it, without an address you cannot use the "&"
	operator, and without an address you cannot pass by reference etc
	etc..

You, if I understand correctly, seem to consider the "lvalue" to be the
_identity_ of the object, while I consider it to be just another
_attribute_ of the object.

And I think that is where our opinions fundamentally really differ, and
that this may be the reason for our violent disagreement.

Can we agree on that?

So when you read the "p = 0" is an lvalue, (and obviously the lvalue is
the same as "p"), then that, in your mind, makes the two identical, and
thus taking the _value_ of "p = 0" must the the same as taking the value
of "p". And THIS is why you consider "lvalue" to be such a crucial point.

Would you agree with this characterization?

I, on the other hand, see the "lvalue"ness from a more low-level
addressing standpoint, and do not consider it to be anything really
special: I do not see the conflict in an expression having the same
_lvalue_ as a variable, yet having a different _value_. They are two
different "dimensions" or attributes of objects, and the lvalue does not
"define" the object.

(So to me, "lvalue" is just "addressable". Nothing more, nothing less.
Of course, being addressable is a _very_ important distinction in any
language, so it's an important attribute, but still only an attribute).

Basically, _if_ I've understood you correctly, I think I understand why we
disagree.

And if so, I think we'll just have to agree to disagree.

Unless I can convince you somehow that "lvalue" isn't as big a deal as you
seem to want to make it ;)

		Linus "_trying_ to understand people" Torvalds


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]