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 inlinedastrees



On Sun, 16 Dec 2001, Jason Merrill wrote:
>
> Evidence:
>
> C99 Standard, Simple assignment:
>
>        In simple assignment (=), the value of the right operand is
>        converted to the type of the assignment expression and replaces the
>        value stored in the object designated by the left operand.
>
> Here, 'the value stored' clearly refers to the value in the object BEFORE
> the assignment.

Hey, finally some valid argument about the _real_ issue.

And, yes, I agree, and I see where you're coming from. You can certainly
parse the passage that way for the assignment operation too. Mea culpa.

> > I further claim that NOWHERE does the standard say that the "lvalue to
> > rvalue conversion" is an "access". Show me. I've quoted the passage, and
> > I've pointed out that nowhere in the definition of "lvalue-rvalue"
> > conversion does it _ever_ say anything about accessing the object
> > associated with the lvalue.
>
> But what else *could* it mean?

It could easily mean that some expressions have the rvalue in and of
themselves, like an assignment.

>				 [conv.lval] says that an l-r conversion
> inside sizeof is not an access.  Does that not suggest to you that such a
> conversion outside sizeof IS an access?

No, it suggests that it sometimes _can_ be. Which makes perfect sense if
it is something that doesn't happen all the time.

In particular, imagine a completely hypothetical operation that inherently
_knows_ what the "value contained within the object" is..

Yeah, right. The "completely hypothetical operation" isn't all that
hypothetical. It's obviously the operation that _sets_ the value.

It's called an assignment.

See, assignments are special. They ihnerently access the object in
themselves. You don't _need_ any other "access" to know what the value is.

In contrast, in the _absense_ of an assignment, how would you know what
the "value contained"?

Right. For _all_ other operations, you have to read it.

That's what makes assignments special. They are the _only_ operations
where you know that the "value contained" is a priori.

Which means that they are also the only operation where the "lvalue to
rvalue conversion" does not have to involve an access.

See my argument?

> Did you ever look at the issues list URL I pointed you at?  Again, the C++
> core language subcommittee discussed this stuff on the email reflector, and
> at the last meeting.  What I'm telling you is the consensus.  Your position
> was brought up, considered, and set aside.  Bring it up on comp.std.c++ if
> you disagree.

I looked at it, but it was marked as (a) still open (ie no conclusion),
and (b) the _basic_ issue there is not "a = b = c", but "(a = b) = c" due
to the need for a sequence point to avoid undefined behaviour for

	(a += b) += c

which otherwise has the "a is read and written multiple times without an
explicit sequence point" problem.

To the (for that discussion) side question as to whether "a = b = 0" reads
b multiple times, there was only disagreement.

The _sequence_point_ issue was relevant not for the case of
"lvalue->rvalue"  conversion at all, but for the "it stays as an lvalue"

Sequence points have little meaning for repeated loads, only for repeated
stores (and ordering between them).

So I don't think that discussion is an issue here.

Your point on "value stored" is well taken, though, and I agree that you
can read it that way.

		Linus


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