Velocity Reviews > tricky assignment statemenent

# tricky assignment statemenent

Jun Woong
Guest
Posts: n/a

 01-12-2005
Lawrence Kirby <(E-Mail Removed)> wrote in message news:<(E-Mail Removed). uk>...
> On Tue, 04 Jan 2005 18:07:59 +0000, Christian Bau wrote:

[...]
> >
> > There are two assignments here. In one assignment, p is modified. The
> > prior value of p is arguably used to determine the new value stored into
> > p, as you explained, but it is _also_ read to determine at which memory
> > location the second assignment will happen, so it is not _only_ read to
> > determine the value stored, therefore undefined behavior.

>

[...]
> In p=p->next=q it is *only* accessed in the expression that calculates the
> new value to be assigned.

But it's *not* that it's accessed *only* to get the new value to be
stored. You seem to already agree with this. Then you should admit it
results in undefined behavior.

> The inner assignment is part of that evaluation,
> the fact that it has another side-effect on a distinct object is neither
> here nor there, why should it be relevant?

--
Jun, Woong (woong at icu.ac.kr)
Information and Communications Univ.

Lawrence Kirby
Guest
Posts: n/a

 01-14-2005
On Tue, 11 Jan 2005 17:36:02 -0800, Jun Woong wrote:

> Lawrence Kirby <(E-Mail Removed)> wrote in message news:<(E-Mail Removed). uk>...
>> On Tue, 04 Jan 2005 18:07:59 +0000, Christian Bau wrote:

> [...]
>> >
>> > There are two assignments here. In one assignment, p is modified. The
>> > prior value of p is arguably used to determine the new value stored into
>> > p, as you explained, but it is _also_ read to determine at which memory
>> > location the second assignment will happen, so it is not _only_ read to
>> > determine the value stored, therefore undefined behavior.

>>

> [...]
>> In p=p->next=q it is *only* accessed in the expression that calculates the
>> new value to be assigned.

>
> But it's *not* that it's accessed *only* to get the new value to be
> stored.

It is accessed as part of the evaluation of the expression that produces
the new value to be stored. That's it, nothing else. Your definition of
"only" is far too woolly to be useful or intended in a standard, it would
require a complex set of definitions to specify what does and doesn't
count as other purposes for the access. Is this well defined: x = abs(x)?
Now how about x = printf("%d", x) and x = myfunc(x)?

> You seem to already agree with this. Then you should admit it
> results in undefined behavior.

I certainly don't agree with that.

>> The inner assignment is part of that evaluation,
>> the fact that it has another side-effect on a distinct object is neither
>> here nor there, why should it be relevant?

>

I've read it. I will post to that thread in due course.

Lawrence

Jun Woong
Guest
Posts: n/a

 01-15-2005

"Lawrence Kirby" <(E-Mail Removed)> wrote in message news(E-Mail Removed) k...
> On Tue, 11 Jan 2005 17:36:02 -0800, Jun Woong wrote:

[...]
> >
> > But it's *not* that it's accessed *only* to get the new value to be
> > stored.

>
> It is accessed as part of the evaluation of the expression that produces
> the new value to be stored. That's it, nothing else.

Many already claimed it to argue the behavior in question defined and
many others already showed it wrong.

> "only" is far too woolly to be useful or intended in a standard,

It's not just my definition. It's the "intended" definition. See what
the committee members here and in csc talk about it.

> it would
> require a complex set of definitions to specify what does and doesn't
> count as other purposes for the access. Is this well defined: x = abs(x)?
> Now how about x = printf("%d", x) and x = myfunc(x)?

We have the sequence point before and after the function calls. So
what's your problem with those expressions?

>
> > You seem to already agree with this. Then you should admit it
> > results in undefined behavior.

>
> I certainly don't agree with that.

Which means that you are simply wrong, at least in the current state
of the standard.

>
> >> The inner assignment is part of that evaluation,
> >> the fact that it has another side-effect on a distinct object is neither
> >> here nor there, why should it be relevant?

> >

>
> I've read it. I will post to that thread in due course.
>

I hope you get more solid base for your argument then.

--
Jun, Woong (woong at icu.ac.kr)
Information and Communications Univ.