Multiple Assignment Evaluation Debate

[ena8t8si@yahoo.com]

Re: Multiple Assignment Evaluation Debate


Vladimir S. Oka wrote:[color=blue]
> On Friday 17 March 2006 04:48, ena8t8si@yahoo. com opined (in
> <1142570915.659 187.13920@i39g2 000cwa.googlegr oups.com>):
>[color=green]
> >
> > pete wrote:[color=darkred]
> >> ena8t8si@yahoo. com wrote:
> >> >
> >> > Micah Cowan wrote:
> >> > > Michael Mair <Michael.Mair@i nvalid.invalid> writes:
> >> > >
> >> > > > Richard G. Riley schrieb:
> >> > > > > On 2006-03-12, pete <pfiland@mindsp ring.com> wrote:
> >> > > > >
> >> > > > >> I'm coming around to thinking that 6.5 [#2] is relevant, and
> >> > > > >> that p = p->next = q
> >> > > > >>is undefined, and not just unspecified.
> >> > > > > but
> >> > > > > p=(p->next=q);
> >> > > > > is fine? I hope .
> >> > > >
> >> > > > No. Whether you write
> >> > > > a = b = c;
> >> > > > or
> >> > > > a = (b = c);
> >> > > > does not change anything -- apart from clarifying your intent.
> >> > > > You still are modifying p twice between sequence points
> >> > >
> >> > > Well, no he's not.
> >> > > But he's reading its prior value for purposes other
> >> > > than to determine the value stored, so same deal.
> >> >
> >> > Look again. Reading p is necessary to evaluate p->q = next,
> >>
> >> No, it isn't.
> >> The value of (p->q = next) is (next)[/color]
> >
> > The value of p->q = next is next. But in order to get the
> > value, the assignment p->q = next must _have been
> > evaluated_, which needed both operands. Evaluation includes
> > all the actions in the Semantics paragraph, which includes
> > starting the side effect of storing the value.[/color]
>
> I think pete is right. The compiler _knows_ that the result of (p->q =
> next) _will_be_ next before it even produces any code, and can use that
> knowledge once it does get to producing some.[/color]

You've fallen into the trap of arguing based on what a
compiler might be capable of. Regardless of what the
compiler knows, it's still obliged to produce code that
behaves according to how the Semantics paragraphs and
everything else in the standard says it must.

[Vladimir S. Oka]

Re: Multiple Assignment Evaluation Debate

On Friday 17 March 2006 15:27, ena8t8si@yahoo. com opined (in
<1142609231.588 389.318260@j52g 2000cwj.googleg roups.com>):
[color=blue]
>
> Vladimir S. Oka wrote:[color=green]
>> On Friday 17 March 2006 04:48, ena8t8si@yahoo. com opined (in
>> <1142570915.659 187.13920@i39g2 000cwa.googlegr oups.com>):
>>[color=darkred]
>> >
>> > pete wrote:
>> >> ena8t8si@yahoo. com wrote:
>> >> >
>> >> > Micah Cowan wrote:
>> >> > > Michael Mair <Michael.Mair@i nvalid.invalid> writes:
>> >> > >
>> >> > > > Richard G. Riley schrieb:
>> >> > > > > On 2006-03-12, pete <pfiland@mindsp ring.com> wrote:
>> >> > > > >
>> >> > > > >> I'm coming around to thinking that 6.5 [#2] is relevant,
>> >> > > > >> and that p = p->next = q
>> >> > > > >>is undefined, and not just unspecified.
>> >> > > > > but
>> >> > > > > p=(p->next=q);
>> >> > > > > is fine? I hope .
>> >> > > >
>> >> > > > No. Whether you write
>> >> > > > a = b = c;
>> >> > > > or
>> >> > > > a = (b = c);
>> >> > > > does not change anything -- apart from clarifying your
>> >> > > > intent. You still are modifying p twice between sequence
>> >> > > > points
>> >> > >
>> >> > > Well, no he's not.
>> >> > > But he's reading its prior value for purposes other
>> >> > > than to determine the value stored, so same deal.
>> >> >
>> >> > Look again. Reading p is necessary to evaluate p->q = next,
>> >>
>> >> No, it isn't.
>> >> The value of (p->q = next) is (next)
>> >
>> > The value of p->q = next is next. But in order to get the
>> > value, the assignment p->q = next must _have been
>> > evaluated_, which needed both operands. Evaluation includes
>> > all the actions in the Semantics paragraph, which includes
>> > starting the side effect of storing the value.[/color]
>>
>> I think pete is right. The compiler _knows_ that the result of (p->q
>> = next) _will_be_ next before it even produces any code, and can use
>> that knowledge once it does get to producing some.[/color]
>
> You've fallen into the trap of arguing based on what a
> compiler might be capable of. Regardless of what the
> compiler knows, it's still obliged to produce code that
> behaves according to how the Semantics paragraphs and
> everything else in the standard says it must.[/color]

But it still does not evaluate p->q in order to assign next to it. What
is evaluated is next, and its value is /assigned/ to p->q. Next, the
assignment is evaluated and assigned to p. The assignment evaluates to
next, but I don't think that compiler is obliged to do that in any
particular way.

--
BR, Vladimir

Writing about music is like dancing about architecture.
-- Frank Zappa

[Chris Torek]

Re: Multiple Assignment Evaluation Debate

[on whether
p = p->next = next;
could have undefined behavior]
[color=blue]
>Vladimir S. Oka wrote:[color=green]
>> I think pete is right. The compiler _knows_ that the result of (p->q =
>> next) _will_be_ next before it even produces any code, and can use that
>> knowledge once it does get to producing some.[/color][/color]

In article <1142609231.588 389.318260@j52g 2000cwj.googleg roups.com>
<ena8t8si@yahoo .com> wrote:[color=blue]
>You've fallen into the trap of arguing based on what a
>compiler might be capable of. Regardless of what the
>compiler knows, it's still obliged to produce code that
>behaves according to how the Semantics paragraphs and
>everything else in the standard says it must.[/color]

This is correct -- in order to claim to compile Standard C, a C
compiler must obey the standard -- but the question is whether
"everything else in the standard" actually *says* that

p = p->next = next;

has to have defined behavior. You and I may think it is bizarre
and wrong if the actual wording in the Standard fails to require
this to work the "obvious" and "correct" way. Unfortunately, those
who argue that both C89 and C99 fail to require this to work, do
in fact seem to have a leg to stand on, as the saying goes.

(The standard has a number of defects, and I consider this to be
one of them, albeit a minor one. Someone's -- I have forgotten
whose -- proposed annex to the C99 standard, with a formal
model for deciding sequence points, would have at least provided
a definitive answer. But that annex did not make it in.)

(There is a simple cure available to the C programmer, though: just
write:

p->next = next, p = next;

instead. We can avoid skating on the thin ice, instead of arguing
about just how thin it may be.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Micah Cowan]

Re: Multiple Assignment Evaluation Debate

ena8t8si@yahoo. com writes:
[color=blue]
> pete wrote:[color=green]
> > No, it isn't.
> > The value of (p->q = next) is (next)[/color]
>
> The value of p->q = next is next. But in order to get the
> value, the assignment p->q = next must _have been
> evaluated_,[/color]

Wrong. The assignment itself need not have taken place. If you really
/did/ understand sequence points, you would know this.

As far as C is concerned, an implementation is more than welcome to do

p = next;
p->q = next;

That's why sequence points are very important.

[Michael Wojcik]

Re: Multiple Assignment Evaluation Debate


In article <87hd60u4qe.fsf @benpfaff.org>, Ben Pfaff <blp@cs.stanfor d.edu> writes:[color=blue]
> You (Robin Haigh) believe that
> p = p->next = q;
> is well defined. Many other people share this opinion. But when
> it was brought up in comp.std.c a long time ago, there were also
> many people with the opposite opinion. If I recall correctly,
> some of these folks were actually committee members.[/color]

It's my feeling that any question of the C standard which leads to
an extended argument between Lawrence Kirby and Douglas Gwyn[1] is
pretty much by definition an unclear matter.

I agree with Ben. It's not productive. Avoid multiple assignments
between sequence points where ordering could be significant, and not
only is the potential problem avoided, but the resulting code will
be simpler and clearer.


1. http://groups.google.com/group/comp....ab46d713d239a2

--
Michael Wojcik michael.wojcik@ microfocus.com

Do not "test" parts, as this may compromise sensitive joinery. Those who
suffer difficulty should abandon the enterprise immediately. -- Chris Ware

[ena8t8si@yahoo.com]

Re: Multiple Assignment Evaluation Debate


Vladimir S. Oka wrote:[color=blue]
> On Friday 17 March 2006 15:27, ena8t8si@yahoo. com opined (in
> <1142609231.588 389.318260@j52g 2000cwj.googleg roups.com>):
>[color=green]
> >
> > Vladimir S. Oka wrote:[color=darkred]
> >> On Friday 17 March 2006 04:48, ena8t8si@yahoo. com opined (in
> >> <1142570915.659 187.13920@i39g2 000cwa.googlegr oups.com>):
> >>
> >> >
> >> > pete wrote:
> >> >> ena8t8si@yahoo. com wrote:
> >> >> >
> >> >> > Micah Cowan wrote:
> >> >> > > Michael Mair <Michael.Mair@i nvalid.invalid> writes:
> >> >> > >
> >> >> > > > Richard G. Riley schrieb:
> >> >> > > > > On 2006-03-12, pete <pfiland@mindsp ring.com> wrote:
> >> >> > > > >
> >> >> > > > >> I'm coming around to thinking that 6.5 [#2] is relevant,
> >> >> > > > >> and that p = p->next = q
> >> >> > > > >>is undefined, and not just unspecified.
> >> >> > > > > but
> >> >> > > > > p=(p->next=q);
> >> >> > > > > is fine? I hope .
> >> >> > > >
> >> >> > > > No. Whether you write
> >> >> > > > a = b = c;
> >> >> > > > or
> >> >> > > > a = (b = c);
> >> >> > > > does not change anything -- apart from clarifying your
> >> >> > > > intent. You still are modifying p twice between sequence
> >> >> > > > points
> >> >> > >
> >> >> > > Well, no he's not.
> >> >> > > But he's reading its prior value for purposes other
> >> >> > > than to determine the value stored, so same deal.
> >> >> >
> >> >> > Look again. Reading p is necessary to evaluate p->q = next,
> >> >>
> >> >> No, it isn't.
> >> >> The value of (p->q = next) is (next)
> >> >
> >> > The value of p->q = next is next. But in order to get the
> >> > value, the assignment p->q = next must _have been
> >> > evaluated_, which needed both operands. Evaluation includes
> >> > all the actions in the Semantics paragraph, which includes
> >> > starting the side effect of storing the value.
> >>
> >> I think pete is right. The compiler _knows_ that the result of (p->q
> >> = next) _will_be_ next before it even produces any code, and can use
> >> that knowledge once it does get to producing some.[/color]
> >
> > You've fallen into the trap of arguing based on what a
> > compiler might be capable of. Regardless of what the
> > compiler knows, it's still obliged to produce code that
> > behaves according to how the Semantics paragraphs and
> > everything else in the standard says it must.[/color]
>
> But it still does not evaluate p->q in order to assign next to it. What
> is evaluated is next, and its value is /assigned/ to p->q. Next, the
> assignment is evaluated and assigned to p. The assignment evaluates to
> next, but I don't think that compiler is obliged to do that in any
> particular way.[/color]

Sorry, the compiler _is_ obliged to do the evaluation as per the
Semantics description. The Semantics paragraphs in 6.5.16
specify _both_ that the store happens and what the value is.
(Yes, the side effect of the store may happen later.) Where in
the standard is there any statement that says an expression
(_any_ expression) may yield a value _before_ it has been
evaluated?

[ena8t8si@yahoo.com]

Re: Multiple Assignment Evaluation Debate


Chris Torek wrote:[color=blue]
> [on whether
> p = p->next = next;
> could have undefined behavior]
>[color=green]
> >Vladimir S. Oka wrote:[color=darkred]
> >> I think pete is right. The compiler _knows_ that the result of (p->q =
> >> next) _will_be_ next before it even produces any code, and can use that
> >> knowledge once it does get to producing some.[/color][/color]
>
> In article <1142609231.588 389.318260@j52g 2000cwj.googleg roups.com>
> <ena8t8si@yahoo .com> wrote:[color=green]
> >You've fallen into the trap of arguing based on what a
> >compiler might be capable of. Regardless of what the
> >compiler knows, it's still obliged to produce code that
> >behaves according to how the Semantics paragraphs and
> >everything else in the standard says it must.[/color]
>
> This is correct -- in order to claim to compile Standard C, a C
> compiler must obey the standard -- but the question is whether
> "everything else in the standard" actually *says* that
>
> p = p->next = next;
>
> has to have defined behavior. You and I may think it is bizarre
> and wrong if the actual wording in the Standard fails to require
> this to work the "obvious" and "correct" way. Unfortunately, those
> who argue that both C89 and C99 fail to require this to work, do
> in fact seem to have a leg to stand on, as the saying goes.[/color]

If you mean there are more than a few people that believe that
p = p->next = next are undefined, I agree with you.

The problem is, none of their arguments are convincing. They all
boil down to the premise that an expression can yield a value
before it has been evaluated. But no one has cited any statement
from the standard that says this is allowed. Usually the arguments
are of the form "I can imagine a compiler doing this, so it must
be allowed." That's a bogus argument.

Let me put it as a question - are you aware of any statement
in the standard that says an expression may yield a value
before it's been evaluated?
[color=blue]
> (The standard has a number of defects, and I consider this to be
> one of them, albeit a minor one. Someone's -- I have forgotten
> whose -- proposed annex to the C99 standard, with a formal
> model for deciding sequence points, would have at least provided
> a definitive answer. But that annex did not make it in.)[/color]

I wonder how many people took the trouble to read _any_ of the
formal models--there are at least three or four generally
available--before considering their positions or framing their
arguments.

[ena8t8si@yahoo.com]

Re: Multiple Assignment Evaluation Debate


Micah Cowan wrote:[color=blue]
> ena8t8si@yahoo. com writes:
>[color=green]
> > pete wrote:[color=darkred]
> > > No, it isn't.
> > > The value of (p->q = next) is (next)[/color]
> >
> > The value of p->q = next is next. But in order to get the
> > value, the assignment p->q = next must _have been
> > evaluated_,[/color]
>
> Wrong. The assignment itself need not have taken place. If you really
> /did/ understand sequence points, you would know this.
>
> As far as C is concerned, an implementation is more than welcome to do
>
> p = next;
> p->q = next;
>
> That's why sequence points are very important.[/color]

Ahh, the old "you don't know what you're talking about" defense.
A bold ploy. Of course your statement presupposes that _you_ do
know what you're talking about. The problem is, you haven't
given any supporting statements for either opinion. Or, for that
matter, your opinion about how p = p->next = q is evaluated.

Any other unsupported opinions you'd like to express?

[Vladimir S. Oka]

Re: Multiple Assignment Evaluation Debate

ena8t8si@yahoo. com opined:
[color=blue]
>
> Vladimir S. Oka wrote:[color=green]
>> On Friday 17 March 2006 15:27, ena8t8si@yahoo. com opined (in
>> <1142609231.588 389.318260@j52g 2000cwj.googleg roups.com>):
>>[color=darkred]
>> >
>> > Vladimir S. Oka wrote:
>> >> On Friday 17 March 2006 04:48, ena8t8si@yahoo. com opined
>> >> (in
>> >> <1142570915.659 187.13920@i39g2 000cwa.googlegr oups.com>):
>> >>
>> >> >
>> >> > pete wrote:
>> >> >> ena8t8si@yahoo. com wrote:
>> >> >> >
>> >> >> > Micah Cowan wrote:
>> >> >> > > Michael Mair <Michael.Mair@i nvalid.invalid> writes:
>> >> >> > >
>> >> >> > > > Richard G. Riley schrieb:
>> >> >> > > > > On 2006-03-12, pete <pfiland@mindsp ring.com>
>> >> >> > > > > wrote:
>> >> >> > > > >
>> >> >> > > > >> I'm coming around to thinking that 6.5 [#2] is
>> >> >> > > > >> relevant, and that p = p->next = q
>> >> >> > > > >>is undefined, and not just unspecified.
>> >> >> > > > > but
>> >> >> > > > > p=(p->next=q);
>> >> >> > > > > is fine? I hope .
>> >> >> > > >
>> >> >> > > > No. Whether you write
>> >> >> > > > a = b = c;
>> >> >> > > > or
>> >> >> > > > a = (b = c);
>> >> >> > > > does not change anything -- apart from clarifying
>> >> >> > > > your intent. You still are modifying p twice
>> >> >> > > > between sequence points
>> >> >> > >
>> >> >> > > Well, no he's not.
>> >> >> > > But he's reading its prior value for purposes other
>> >> >> > > than to determine the value stored, so same deal.
>> >> >> >
>> >> >> > Look again. Reading p is necessary to evaluate p->q
>> >> >> > = next,
>> >> >>
>> >> >> No, it isn't.
>> >> >> The value of (p->q = next) is (next)
>> >> >
>> >> > The value of p->q = next is next. But in order to get
>> >> > the value, the assignment p->q = next must _have been
>> >> > evaluated_, which needed both operands. Evaluation
>> >> > includes all the actions in the Semantics paragraph,
>> >> > which includes starting the side effect of storing the
>> >> > value.
>> >>
>> >> I think pete is right. The compiler _knows_ that the
>> >> result of (p->q = next) _will_be_ next before it even
>> >> produces any code, and can use that knowledge once it does
>> >> get to producing some.
>> >
>> > You've fallen into the trap of arguing based on what a
>> > compiler might be capable of. Regardless of what the
>> > compiler knows, it's still obliged to produce code that
>> > behaves according to how the Semantics paragraphs and
>> > everything else in the standard says it must.[/color]
>>
>> But it still does not evaluate p->q in order to assign next
>> to it. What is evaluated is next, and its value is /assigned/
>> to p->q. Next, the assignment is evaluated and assigned to p.
>> The assignment evaluates to next, but I don't think that
>> compiler is obliged to do that in any particular way.[/color]
>
> Sorry, the compiler _is_ obliged to do the evaluation as per
> the Semantics description. The Semantics paragraphs in 6.5.16
> specify _both_ that the store happens and what the value is.
> (Yes, the side effect of the store may happen later.) Where
> in the standard is there any statement that says an expression
> (_any_ expression) may yield a value _before_ it has been
> evaluated?[/color]

Ok, now my head starts to spin a bit, but bear with me...

Is it right that the original problem statement was:

p = p->next = q;

Assuming it was: `p` is not modified twice, it is read once to
get `next`, and modified once to assign value to it in the
leftmost assignment. Assigning value to `next` does not modify
`p`, right?

Now, I re-read what 6.5.16 has to say, and yes, I know examples
are not normative, but to me Example 2 (6.5.16.1p5) seems to
support the following interpretation of the above statement:

1) `q` is evaluated
2) its value is assigned to `p->next`
3) that value becomes the value of the rightmost assignment
4) that value is assigned to `p`

I read that it happens in the order I give above. Also, `p` is
modified only once (4), and read only once (2).

I think this, now, expresses how I see what happens, and my
reading of the Standard. If it isn't what I said before, it's
completely my fault (assign 20% to English being my second
language).

--
BR, Vladimir

I have seen these EGG EXTENDERS in my Supermarket ...

[ena8t8si@yahoo.com]

Re: Multiple Assignment Evaluation Debate


Vladimir S. Oka wrote:[color=blue]
> ena8t8si@yahoo. com opined:
>[color=green]
> >
> > Vladimir S. Oka wrote:[color=darkred]
> >> On Friday 17 March 2006 15:27, ena8t8si@yahoo. com opined (in
> >> <1142609231.588 389.318260@j52g 2000cwj.googleg roups.com>):
> >>
> >> >
> >> > Vladimir S. Oka wrote:
> >> >> On Friday 17 March 2006 04:48, ena8t8si@yahoo. com opined
> >> >> (in
> >> >> <1142570915.659 187.13920@i39g2 000cwa.googlegr oups.com>):
> >> >>
> >> >> >
> >> >> > pete wrote:
> >> >> >> ena8t8si@yahoo. com wrote:
> >> >> >> >
> >> >> >> > Micah Cowan wrote:
> >> >> >> > > Michael Mair <Michael.Mair@i nvalid.invalid> writes:
> >> >> >> > >
> >> >> >> > > > Richard G. Riley schrieb:
> >> >> >> > > > > On 2006-03-12, pete <pfiland@mindsp ring.com>
> >> >> >> > > > > wrote:
> >> >> >> > > > >
> >> >> >> > > > >> I'm coming around to thinking that 6.5 [#2] is
> >> >> >> > > > >> relevant, and that p = p->next = q
> >> >> >> > > > >>is undefined, and not just unspecified.
> >> >> >> > > > > but
> >> >> >> > > > > p=(p->next=q);
> >> >> >> > > > > is fine? I hope .
> >> >> >> > > >
> >> >> >> > > > No. Whether you write
> >> >> >> > > > a = b = c;
> >> >> >> > > > or
> >> >> >> > > > a = (b = c);
> >> >> >> > > > does not change anything -- apart from clarifying
> >> >> >> > > > your intent. You still are modifying p twice
> >> >> >> > > > between sequence points
> >> >> >> > >
> >> >> >> > > Well, no he's not.
> >> >> >> > > But he's reading its prior value for purposes other
> >> >> >> > > than to determine the value stored, so same deal.
> >> >> >> >
> >> >> >> > Look again. Reading p is necessary to evaluate p->q
> >> >> >> > = next,
> >> >> >>
> >> >> >> No, it isn't.
> >> >> >> The value of (p->q = next) is (next)
> >> >> >
> >> >> > The value of p->q = next is next. But in order to get
> >> >> > the value, the assignment p->q = next must _have been
> >> >> > evaluated_, which needed both operands. Evaluation
> >> >> > includes all the actions in the Semantics paragraph,
> >> >> > which includes starting the side effect of storing the
> >> >> > value.
> >> >>
> >> >> I think pete is right. The compiler _knows_ that the
> >> >> result of (p->q = next) _will_be_ next before it even
> >> >> produces any code, and can use that knowledge once it does
> >> >> get to producing some.
> >> >
> >> > You've fallen into the trap of arguing based on what a
> >> > compiler might be capable of. Regardless of what the
> >> > compiler knows, it's still obliged to produce code that
> >> > behaves according to how the Semantics paragraphs and
> >> > everything else in the standard says it must.
> >>
> >> But it still does not evaluate p->q in order to assign next
> >> to it. What is evaluated is next, and its value is /assigned/
> >> to p->q. Next, the assignment is evaluated and assigned to p.
> >> The assignment evaluates to next, but I don't think that
> >> compiler is obliged to do that in any particular way.[/color]
> >
> > Sorry, the compiler _is_ obliged to do the evaluation as per
> > the Semantics description. The Semantics paragraphs in 6.5.16
> > specify _both_ that the store happens and what the value is.
> > (Yes, the side effect of the store may happen later.) Where
> > in the standard is there any statement that says an expression
> > (_any_ expression) may yield a value _before_ it has been
> > evaluated?[/color]
>
> Ok, now my head starts to spin a bit, but bear with me...
>
> Is it right that the original problem statement was:
>
> p = p->next = q;[/color]

Yes.
[color=blue]
> Assuming it was: `p` is not modified twice, it is read once to
> get `next`, and modified once to assign value to it in the
> leftmost assignment. Assigning value to `next` does not modify
> `p`, right?
>
> Now, I re-read what 6.5.16 has to say, and yes, I know examples
> are not normative, but to me Example 2 (6.5.16.1p5) seems to
> support the following interpretation of the above statement:
>
> 1) `q` is evaluated
> 2) its value is assigned to `p->next`
> 3) that value becomes the value of the rightmost assignment
> 4) that value is assigned to `p`
>
> I read that it happens in the order I give above. Also, `p` is
> modified only once (4), and read only once (2).[/color]

Yes. Also the side effect of updating the value of p->next
can happen any time after (2), and the side effect of updating
the value of p can happen any time after (4).
[color=blue]
> I think this, now, expresses how I see what happens, and my
> reading of the Standard. If it isn't what I said before, it's
> completely my fault (assign 20% to English being my second
> language).[/color]

[Vladimir S. Oka]

Re: Multiple Assignment Evaluation Debate

ena8t8si@yahoo. com opined:
[color=blue]
>
> Vladimir S. Oka wrote:[color=green]
>> ena8t8si@yahoo. com opined:
>>[color=darkred]
>> >
>> > Vladimir S. Oka wrote:
>> >> On Friday 17 March 2006 15:27, ena8t8si@yahoo. com opined (in
>> >> <1142609231.588 389.318260@j52g 2000cwj.googleg roups.com>):
>> >>
>> >> >
>> >> > Vladimir S. Oka wrote:
>> >> >> On Friday 17 March 2006 04:48, ena8t8si@yahoo. com opined
>> >> >> (in
>> >> >> <1142570915.659 187.13920@i39g2 000cwa.googlegr oups.com>):
>> >> >>
>> >> >> >
>> >> >> > pete wrote:
>> >> >> >> ena8t8si@yahoo. com wrote:
>> >> >> >> >
>> >> >> >> > Micah Cowan wrote:
>> >> >> >> > > Michael Mair <Michael.Mair@i nvalid.invalid> writes:
>> >> >> >> > >
>> >> >> >> > > > Richard G. Riley schrieb:
>> >> >> >> > > > > On 2006-03-12, pete <pfiland@mindsp ring.com>
>> >> >> >> > > > > wrote:
>> >> >> >> > > > >
>> >> >> >> > > > >> I'm coming around to thinking that 6.5 [#2] is
>> >> >> >> > > > >> relevant, and that p = p->next = q
>> >> >> >> > > > >>is undefined, and not just unspecified.
>> >> >> >> > > > > but
>> >> >> >> > > > > p=(p->next=q);
>> >> >> >> > > > > is fine? I hope .
>> >> >> >> > > >
>> >> >> >> > > > No. Whether you write
>> >> >> >> > > > a = b = c;
>> >> >> >> > > > or
>> >> >> >> > > > a = (b = c);
>> >> >> >> > > > does not change anything -- apart from clarifying
>> >> >> >> > > > your intent. You still are modifying p twice
>> >> >> >> > > > between sequence points
>> >> >> >> > >
>> >> >> >> > > Well, no he's not.
>> >> >> >> > > But he's reading its prior value for purposes other
>> >> >> >> > > than to determine the value stored, so same deal.
>> >> >> >> >
>> >> >> >> > Look again. Reading p is necessary to evaluate p->q
>> >> >> >> > = next,
>> >> >> >>
>> >> >> >> No, it isn't.
>> >> >> >> The value of (p->q = next) is (next)
>> >> >> >
>> >> >> > The value of p->q = next is next. But in order to get
>> >> >> > the value, the assignment p->q = next must _have been
>> >> >> > evaluated_, which needed both operands. Evaluation
>> >> >> > includes all the actions in the Semantics paragraph,
>> >> >> > which includes starting the side effect of storing the
>> >> >> > value.
>> >> >>
>> >> >> I think pete is right. The compiler _knows_ that the
>> >> >> result of (p->q = next) _will_be_ next before it even
>> >> >> produces any code, and can use that knowledge once it does
>> >> >> get to producing some.
>> >> >
>> >> > You've fallen into the trap of arguing based on what a
>> >> > compiler might be capable of. Regardless of what the
>> >> > compiler knows, it's still obliged to produce code that
>> >> > behaves according to how the Semantics paragraphs and
>> >> > everything else in the standard says it must.
>> >>
>> >> But it still does not evaluate p->q in order to assign next
>> >> to it. What is evaluated is next, and its value is /assigned/
>> >> to p->q. Next, the assignment is evaluated and assigned to p.
>> >> The assignment evaluates to next, but I don't think that
>> >> compiler is obliged to do that in any particular way.
>> >
>> > Sorry, the compiler _is_ obliged to do the evaluation as per
>> > the Semantics description. The Semantics paragraphs in 6.5.16
>> > specify _both_ that the store happens and what the value is.
>> > (Yes, the side effect of the store may happen later.) Where
>> > in the standard is there any statement that says an expression
>> > (_any_ expression) may yield a value _before_ it has been
>> > evaluated?[/color]
>>
>> Ok, now my head starts to spin a bit, but bear with me...
>>
>> Is it right that the original problem statement was:
>>
>> p = p->next = q;[/color]
>
> Yes.
>[color=green]
>> Assuming it was: `p` is not modified twice, it is read once to
>> get `next`, and modified once to assign value to it in the
>> leftmost assignment. Assigning value to `next` does not modify
>> `p`, right?
>>
>> Now, I re-read what 6.5.16 has to say, and yes, I know examples
>> are not normative, but to me Example 2 (6.5.16.1p5) seems to
>> support the following interpretation of the above statement:
>>
>> 1) `q` is evaluated
>> 2) its value is assigned to `p->next`
>> 3) that value becomes the value of the rightmost assignment
>> 4) that value is assigned to `p`
>>
>> I read that it happens in the order I give above. Also, `p` is
>> modified only once (4), and read only once (2).[/color]
>
> Yes. Also the side effect of updating the value of p->next
> can happen any time after (2), and the side effect of updating
> the value of p can happen any time after (4).[/color]

I agree.

However, what is the side effect of updating `p->next`? It's just plain
storing a value into a variable. Again, `p` is not modified, AFAICT.
It's the struct member `next` that is, and `p` is just read to get its
address (`next`'s address).

Whether there's any side effect of updating `p` after (4) is, IMO,
irrelevant to the discussion (again, I can't see any side effect of
storing a value into variable).

I still think the operation in this case has to be equivalent to:

p->next = q;
p = p->next;

--
BR, Vladimir

A lad, at his first copulation,
Cried, "What a sensation! Inflation,
Gyration, elation
Throughout the duration,
I guess I'll give up masturbation."

[lawrence.jones@ugs.com]

Re: Multiple Assignment Evaluation Debate

Vladimir S. Oka <novine@btopenw orld.com> wrote:[color=blue]
>
> Now, I re-read what 6.5.16 has to say, and yes, I know examples
> are not normative, but to me Example 2 (6.5.16.1p5) seems to
> support the following interpretation of the above statement:
>
> 1) `q` is evaluated
> 2) its value is assigned to `p->next`
> 3) that value becomes the value of the rightmost assignment
> 4) that value is assigned to `p`[/color]

It's a bit more complicated than that. First, the top-level assignment
expression (p = p->next = q) is evaluated. That requires evaluating the
left side (p) to determine the location to store into and evaluating the
right side (p->next = q) to determine the value to store. Those
evaluations can occur in either order. Evaluating the left side is
trivial, but the right side is again an assignment expression, so it is
necessary to evaluate the left side (p->next) to determine a location to
store into and the right side (q) to determine the value to be stored,
again in any order. This time the right side is trivial, but evaluating
the left side requires evaluating p. So, there are *lots* of
evaluations, which are only loosely ordered.

-Larry Jones

Something COULD happen today. And if anything DOES,
by golly, I'm going to be ready for it! -- Calvin

[Vladimir S. Oka]

Re: Multiple Assignment Evaluation Debate

lawrence.jones@ ugs.com opined:
[color=blue]
> Vladimir S. Oka <novine@btopenw orld.com> wrote:[color=green]
>>
>> Now, I re-read what 6.5.16 has to say, and yes, I know examples
>> are not normative, but to me Example 2 (6.5.16.1p5) seems to
>> support the following interpretation of the above statement:
>>
>> 1) `q` is evaluated
>> 2) its value is assigned to `p->next`
>> 3) that value becomes the value of the rightmost assignment
>> 4) that value is assigned to `p`[/color]
>
> It's a bit more complicated than that. First, the top-level
> assignment expression (p = p->next = q) is evaluated. That requires
> evaluating the left side (p) to determine the location to store into
> and evaluating the right side (p->next = q) to determine the value to
> store. Those evaluations can occur in either order.[/color]

I admit that the normative text of the standard does allow (but not
mandate) such behaviour. However, as I have pointed earlier, the
Example 2 (non-normative, as examples are) suggests that the order of
evaluation is right-to-left.
[color=blue]
> Evaluating the left side is trivial, but the right side is again an
> assignment expression, so it is necessary to evaluate the left side
> (p->next) to determine a location to store into and the right side
> (q) to determine the value to be stored, again in any order. This
> time the right side is trivial, but evaluating the left side requires
> evaluating p. So, there are *lots* of evaluations, which are only
> loosely ordered.[/color]

I know that modifying a value multiple times between sequence points
results in UB, I don't think evaluating something multiple times
(without modifying it multiple times) is a problem.

--
BR, Vladimir

Technological progress has merely provided us
with more efficient means for going backwards.
-- Aldous Huxley

[lawrence.jones@ugs.com]

Re: Multiple Assignment Evaluation Debate

Vladimir S. Oka <novine@btopenw orld.com> wrote:[color=blue]
>
> lawrence.jones@ ugs.com opined:[color=green]
>>
>> It's a bit more complicated than that. First, the top-level
>> assignment expression (p = p->next = q) is evaluated. That requires
>> evaluating the left side (p) to determine the location to store into
>> and evaluating the right side (p->next = q) to determine the value to
>> store. Those evaluations can occur in either order.[/color]
>
> I admit that the normative text of the standard does allow (but not
> mandate) such behaviour. However, as I have pointed earlier, the
> Example 2 (non-normative, as examples are) suggests that the order of
> evaluation is right-to-left.[/color]

No, it most certainly does not. Example 2 is primarily concerned with
the result type of assignment expressions, not order of evaluation.
About the only thing that it implies about order of evaluation is that
an operator's operands must be evaluated before the final result of the
operation is known, but it says nothing whatsoever about the order in
which the operands are evaluated. Compiler can, and do, evaluate
operands in various orders. In fact, a common strategy is to evaluate
the most complex operand first.
[color=blue]
> I know that modifying a value multiple times between sequence points
> results in UB, I don't think evaluating something multiple times
> (without modifying it multiple times) is a problem.[/color]

It is if there is at least one modification and the other evaluations
aren't "read only to determine the value to be stored" (6.5p2).

-Larry Jones

There's a connection here, I just know it. -- Calvin

[Vladimir S. Oka]

Re: Multiple Assignment Evaluation Debate

lawrence.jones@ ugs.com opined:
[color=blue]
> Vladimir S. Oka <novine@btopenw orld.com> wrote:[color=green]
>>
>> lawrence.jones@ ugs.com opined:[color=darkred]
>>>
>>> It's a bit more complicated than that. First, the top-level
>>> assignment expression (p = p->next = q) is evaluated. That
>>> requires evaluating the left side (p) to determine the location to
>>> store into and evaluating the right side (p->next = q) to determine
>>> the value to
>>> store. Those evaluations can occur in either order.[/color]
>>
>> I admit that the normative text of the standard does allow (but not
>> mandate) such behaviour. However, as I have pointed earlier, the
>> Example 2 (non-normative, as examples are) suggests that the order
>> of evaluation is right-to-left.[/color]
>
> No, it most certainly does not. Example 2 is primarily concerned
> with the result type of assignment expressions, not order of
> evaluation. About the only thing that it implies about order of
> evaluation is that an operator's operands must be evaluated before
> the final result of the operation is known, but it says nothing
> whatsoever about the order in
> which the operands are evaluated.[/color]

So, according to what you just said, in order to execute:

p = p->next = q;

the right assignment has to be done first. Otherwise, the final result
is not known and the left assignment cannot happen. Hence, the right
one must be executed first, QED. Executing the right assignment does
not modify `p`, so there's no multiple modifications between sequence
points, and no UB (`p` is modified once, and `p->next` is modified
once -- that's it).
[color=blue]
> Compiler can, and do, evaluate
> operands in various orders. In fact, a common strategy is to
> evaluate the most complex operand first.
>[color=green]
>> I know that modifying a value multiple times between sequence points
>> results in UB, I don't think evaluating something multiple times
>> (without modifying it multiple times) is a problem.[/color]
>
> It is if there is at least one modification and the other evaluations
> aren't "read only to determine the value to be stored" (6.5p2).[/color]

--
BR, Vladimir

Bubble Memory, n.:
A derogatory term, usually referring to a person's
intelligence. See also "vacuum tube".