Hi,
let's have a look on the following expression :

*ptr++ = var;

My question is, does that expression produces UB?

Quote from n1256.pdf 6.5.2
"Between the previous and next sequence point an object shall have its
stored value modified at most once by the evaluation of an
expression.72) Furthermore, the prior value shall be read only to
determine the value to be stored.73)"

In the expression above the prior value is read to determine _where to
store_ value hold by "var" but that value should be read only to
determine _value to be stored_. If I understand quoted part of the
standard this should lead to UB, but ive seen such and similar
expressions so many times that I don't really believe that they are UB.

In <87pra09g53.fsf@pro.wp.pl>, Dominik Zaczkowski wrote:

> 
> Hi,
> let's have a look on the following expression :
> 
> *ptr++ = var;
> 
> My question is, does that expression produces UB?

No.

> Quote from n1256.pdf 6.5.2
> "Between the previous and next sequence point an object shall have
> its stored value modified at most once by the evaluation of an
> expression.72) Furthermore, the prior value shall be read only to
> determine the value to be stored.73)"

Right.

> In the expression above the prior value is read to determine _where
> to store_ value hold by "var" but that value should be read only to
> determine _value to be stored_

No. There are three objects here: var, ptr, and *ptr (the object 
pointed to by ptr). I hope we can both agree that var doesn't present 
a problem, so that leaves us with ptr and *ptr.

Since ++ has the same precedence as unary-*, we use associativity to 
disentangle them. Their associativity is right to left, so ++ takes 
not-exactly-precedence over * on this occasion. The ++ operates on 
its operand, which is ptr (most emphatically NOT *ptr). To perform 
this operation requires the value of ptr to be read, so that the 
value (i.e. ptr+1) to be stored in ptr can be determined. This is not 
UB, any more than i++; is UB.

The value yielded by the postfix ++ operator is the value its operand 
had at the previous sequence point. It is this value which becomes 
the operand of *. The result of /that/ operation is a modifiable 
lvalue to which the value var is assigned, and that isn't UB any more 
than x = y is UB.


> If I understand quoted part of the
> standard this should lead to UB, but ive seen such and similar
> expressions so many times that I don't really believe that they are
> UB.

They're not.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Thank You Richard, so in one sentence the answer would be: It's not UB
becouse value of ptr is not read by *ptr++, * operator "reads" value
yielded by ++ operator.

In <87vdjs7yf9.fsf@pro.wp.pl>, Dominik Zaczkowski wrote:

> Thank You Richard, so in one sentence the answer would be: It's not
> UB becouse value of ptr is not read by *ptr++, * operator "reads"
> value yielded by ++ operator.

That would be a reasonable executive summary, yes. :-)

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

On 9 Sep, 20:45, Richard Heathfield <r...@see.sig.invalid> wrote:
> In <87vdjs7yf9....@pro.wp.pl>, Dominik Zaczkowski wrote:

> > Thank You Richard, so in one sentence the answer would be: It's not
> > UB becouse value of ptr is not read by *ptr++, * operator "reads"
> > value yielded by ++ operator.
>
> That would be a reasonable executive summary, yes. :-)

John said, "Look Janet there is the value yielded by the ++ operator!"

Richard

I was puzzled the first time I read the second sentence of the
Standard quoted below, and I'm afraid I'm still confused. It seems to
make some normal-looking statements, such as the one below, into UB.
Presumably I'm reading it wrong. Could you go over it one more time,
please?

On 9 Sep, 19:32, Richard Heathfield <r...@see.sig.invalid> wrote:
> In <87pra09g53....@pro.wp.pl>, Dominik Zaczkowski wrote:
>
> > Hi,
> > let's have a look on the following expression :
>
> > *ptr++ = var;

For the sake of argument, let's assume that ptr has the value 3 before
this statement is executed, and has the value 4 afterwards. (I realise
that pointers do not have to be numbers.)

> > My question is, does that expression produces UB?
>
> No.
>
> > Quote from n1256.pdf 6.5.2
> > "Between the previous and next sequence point an object shall have
> > its stored value modified at most once by the evaluation of an
> > expression.72) Furthermore, the prior value shall be read only to
> > determine the value to be stored.73)"
>
> Right.
>
> > In the expression above the prior value is read to determine _where
> > to store_ value hold by "var" but that value should be read only to
> > determine _value to be stored_
>
> No. There are three objects here: var, ptr, and *ptr (the object
> pointed to by ptr). I hope we can both agree that var doesn't present
> a problem, so that leaves us with ptr and *ptr.
>
> Since ++ has the same precedence as unary-*, we use associativity to
> disentangle them. Their associativity is right to left, so ++ takes
> not-exactly-precedence over * on this occasion. The ++ operates on
> its operand, which is ptr (most emphatically NOT *ptr).

OK so far.

> To perform
> this operation requires the value of ptr to be read,

We read it. It's 3.

> so that the
> value (i.e. ptr+1) to be stored in ptr can be determined.

We calculate 3+1, and so at some point we will store 4 in ptr. We are
allowed to use the value we have read to do this. We're not allowed to
use the value (3) for anything else.

> This is not
> UB, any more than i++; is UB.
>
> The value yielded by the postfix ++ operator is the value its operand
> had at the previous sequence point.

Yes, it's the 3 we read earlier, *but* we are not (apparently) allowed
to use it for this. The standard says "the prior value shall be read
only to determine the value to be stored". I presume "stored" here
means "stored in &ptr", ie the new value of ptr.

> It is this value which becomes
> the operand of *.

But we're not allowed to use it for that! We're not using the 3 to
work out what the new value of ptr is, we're using it to calculate a
memory address to which we are going to write (the value of) var.

> The result of /that/ operation is a modifiable
> lvalue to which the value var is assigned, and that isn't UB any more
> than x = y is UB.
>
> > If I understand quoted part of the
> > standard this should lead to UB, but ive seen such and similar
> > expressions so many times that I don't really believe that they are
> > UB.
>
> They're not.

I wouldn't expect the quoted statement to be UB, but I just can't see
how it complies with the second sentence.

Any help welcome!
Paul.

On 2009-09-10, Richard Heathfield <rjh@see.sig.invalid> wrote:
> We perform the ++ operation, which uses p's value 
> (only to determine the value to be stored in p), and yields a pointer 
> value. This pointer value happens to be the same value that p had at 
> the previous sequence point, but it is NOT p ITSELF. It's just a 
> pointer value. If you like, it's &zog[0].

Yes.

I had to think about this for a while myself, but:

It isn't undefined behavior to use the result of a calculation, which
result happens to be the same as the prior value of x, for purposes
other than computing the new value of x.  It is only undefined behavior
to read from x for other purposes.  We never do.  The result of "x++" isn't
x, it's an expression result which happens to have the value that x had
before the sequence point.  We are not reading x when we use that value.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 2009-09-10, Richard Heathfield <rjh@see.sig.invalid> wrote:
> In <slrnhais7v.m6a.usenet-nospam@guild.seebs.net>, Seebs wrote:
>> -s

> wb - ltnc

Heya.  Suddenly realized that the usenet account I got a while back to
run clcm could probably actually be used.  Had a really busy year, starting
to unwind a bit, thought "hey, usenet was sorta fun, and I am actually
working with compilers full time now".

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

In 
<c4d67d87-6cd4-4513-a38e-e2f289b97f7f@y42g2000yqb.googlegroups.com>, 
Paul N wrote:

> Richard
> 
> I was puzzled the first time I read the second sentence of the
> Standard quoted below, and I'm afraid I'm still confused. It seems
> to make some normal-looking statements, such as the one below, into
> UB. Presumably I'm reading it wrong. Could you go over it one more
> time, please?

Context: *p++ = var;

Okay, let's do a frinstance. var is 6, okay? (Naturally.)

I'm reluctant to describe p with a number, so let's start off with:

int zog[] = { 0xA, 0xB, 0xC, 0xD };

int *p = zog;

So p points to zog[0], i.e. the element with value currently 0xA.

Precedence and associativity give us this AST:

       =
      / \
     *   var
    /
   ++ (post)
  /
 p

We start off (okay, take all when-it-happens phrases with a pinch of 
salt, because we might *not* start off...) by accessing p. We do this 
so that we can perform the ++ operation, which will, before the next 
sequence point, increment p so that it points to zog[1], the element 
with value 0xB. We perform the ++ operation, which uses p's value 
(only to determine the value to be stored in p), and yields a pointer 
value. This pointer value happens to be the same value that p had at 
the previous sequence point, but it is NOT p ITSELF. It's just a 
pointer value. If you like, it's &zog[0].

So... it is this value, not the current value of p, that is yielded by 
++. It is necessary to distinguish between them because it is not 
clear at this stage what p's value actually is. It might be &zog[0] 
or it might be &zog[1], and only the optimiser knows which!

After that, it's plain sailing - the value yielded by ++ (which, 
remember, is a different concept to the value of p, even if it 
happens to be the same number right now, which it may or may not be) 
becomes the operand of *, and that gives us the object zog[0], to 
which we assign the value var, and we're done.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

In <slrnhais7v.m6a.usenet-nospam@guild.seebs.net>, Seebs wrote:

<snip>
 
> -s

wb - ltnc

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

In <slrnhaisra.d1v.usenet-nospam@guild.seebs.net>, Seebs wrote:

<snip>

> Had a really busy
> year, starting to unwind a bit, thought "hey, usenet was sorta fun,
> and I am actually working with compilers full time now".

"Once more I have discovered Usenet, and once more I will never get 
anything done" - Anon.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Paul N <gw7rib@aol.com> writes:
> I was puzzled the first time I read the second sentence of the
> Standard quoted below, and I'm afraid I'm still confused. It seems to
> make some normal-looking statements, such as the one below, into UB.
> Presumably I'm reading it wrong. Could you go over it one more time,
> please?
[snip]

The quotation in question is C99 6.5p2 (I'm quoting from n1256):

    Between the previous and next sequence point an object shall have
    its stored value modified at most once by the evaluation of an
    expression. Furthermore, the prior value shall be read only to
    determine the value to be stored.

I always had some trouble understanding that passage myself; it seemed
like it was anthropomorphizing the program by talking about the
*purpose* for which it did something.

The C201X draft (the latest I have is
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1362.pdf>) changes
the wording so, rather than sequence points, it discusses operations
that are sequenced relative to each other, i.e., cases where one
operation must occur after another because it depends on the other
operation's result.

Here's what 6.5p1-2 says in the draft:

    An expression is a sequence of operators and operands that
    specifies computation of a value, or that designates an object
    or a function, or that generates side effects, or that performs
    a combination thereof. The value computations of the operands
    of an operator are sequenced before the value computation of
    the result of the operator.

    If a side effect on a scalar object is unsequenced relative to
    either a different side effect on the same scalar object or a
    value computation using the value of the same scalar object,
    the behavior is undefined. If there are multiple allowable
    orderings of the subexpressions of an expression, the behavior
    is undefined if such an unsequenced side effect occurs in any
    of the orderings.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Paul N wrote:
> Richard
> 
> I was puzzled the first time I read the second sentence of the
> Standard quoted below, and I'm afraid I'm still confused. It seems to
> make some normal-looking statements, such as the one below, into UB.
> Presumably I'm reading it wrong. Could you go over it one more time,
> please?

You are reading how the ++ operator (both of them) works wrong.

> On 9 Sep, 19:32, Richard Heathfield <r...@see.sig.invalid> wrote:
>> In <87pra09g53....@pro.wp.pl>, Dominik Zaczkowski wrote:
>>
>>> Hi,
>>> let's have a look on the following expression :
>>> *ptr++ = var;
> 
> For the sake of argument, let's assume that ptr has the value 3 before
> this statement is executed, and has the value 4 afterwards. (I realise
> that pointers do not have to be numbers.)

OK so far.

>>> My question is, does that expression produces UB?
>> No.
>>
>>> Quote from n1256.pdf 6.5.2
>>> "Between the previous and next sequence point an object shall have
>>> its stored value modified at most once by the evaluation of an
>>> expression.72) Furthermore, the prior value shall be read only to
>>> determine the value to be stored.73)"
>> Right.
>>
>>> In the expression above the prior value is read to determine _where
>>> to store_ value hold by "var" but that value should be read only to
>>> determine _value to be stored_
>> No. There are three objects here: var, ptr, and *ptr (the object
>> pointed to by ptr). I hope we can both agree that var doesn't present
>> a problem, so that leaves us with ptr and *ptr.
>>
>> Since ++ has the same precedence as unary-*, we use associativity to
>> disentangle them. Their associativity is right to left, so ++ takes
>> not-exactly-precedence over * on this occasion. The ++ operates on
>> its operand, which is ptr (most emphatically NOT *ptr).
> 
> OK so far.

Good.

>> To perform
>> this operation requires the value of ptr to be read,
> 
> We read it. It's 3.

Yes.

>> so that the
>> value (i.e. ptr+1) to be stored in ptr can be determined.
> 
> We calculate 3+1, and so at some point we will store 4 in ptr. We are
> allowed to use the value we have read to do this.

Yes.

> We're not allowed to
> use the value (3) for anything else.

Not relevant, it is a different value (3) that will be used..

>> This is not
>> UB, any more than i++; is UB.
>>
>> The value yielded by the postfix ++ operator is the value its operand
>> had at the previous sequence point.
> 
> Yes, it's the 3 we read earlier,

Wrong. The (3) you get here is a completely new and different (3). Just 
as if you have the code...
    x = 2 * y + 2 * z;
you have two completely different values which both happen to be 2. The 
first value 2 is the result of the first expression 2 and the second 
value 2 is the result of the second value 2!

If you meet a pair of twins, do you think they are both the same person, 
or just two people who happen to be identical?

> *but* we are not (apparently) allowed
> to use it for this.

It's not the same (3) so you are OK :-)

> The standard says "the prior value shall be read
> only to determine the value to be stored". I presume "stored" here
> means "stored in &ptr", ie the new value of ptr.

<snip>

You meant sored in ptr, but yes you are correct. Just wrong to think it 
is the same (3).
-- 
Flash Gordon

Unfortunately, I'm still confused...

On 10 Sep, 23:28, Flash Gordon <s...@spam.causeway.com> wrote:
> Paul N wrote:
> > Richard
>
> > I was puzzled the first time I read the second sentence of the
> > Standard quoted below, and I'm afraid I'm still confused. It seems to
> > make some normal-looking statements, such as the one below, into UB.
> > Presumably I'm reading it wrong. Could you go over it one more time,
> > please?
>
> You are reading how the ++ operator (both of them) works wrong.
>
> > On 9 Sep, 19:32, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> In <87pra09g53....@pro.wp.pl>, Dominik Zaczkowski wrote:
>
> >>> Hi,
> >>> let's have a look on the following expression :
> >>> *ptr++ =3D var;
>
> > For the sake of argument, let's assume that ptr has the value 3 before
> > this statement is executed, and has the value 4 afterwards. (I realise
> > that pointers do not have to be numbers.)
>
> OK so far.
>
>
>
>
>
> >>> My question is, does that expression produces UB?
> >> No.
>
> >>> Quote from n1256.pdf 6.5.2
> >>> "Between the previous and next sequence point an object shall have
> >>> its stored value modified at most once by the evaluation of an
> >>> expression.72) Furthermore, the prior value shall be read only to
> >>> determine the value to be stored.73)"
> >> Right.
>
> >>> In the expression above the prior value is read to determine _where
> >>> to store_ value hold by "var" but that value should be read only to
> >>> determine _value to be stored_
> >> No. There are three objects here: var, ptr, and *ptr (the object
> >> pointed to by ptr). I hope we can both agree that var doesn't present
> >> a problem, so that leaves us with ptr and *ptr.
>
> >> Since ++ has the same precedence as unary-*, we use associativity to
> >> disentangle them. Their associativity is right to left, so ++ takes
> >> not-exactly-precedence over * on this occasion. The ++ operates on
> >> its operand, which is ptr (most emphatically NOT *ptr).
>
> > OK so far.
>
> Good.
>
> >> To perform
> >> this operation requires the value of ptr to be read,
>
> > We read it. It's 3.
>
> Yes.
>
> >> so that the
> >> value (i.e. ptr+1) to be stored in ptr can be determined.
>
> > We calculate 3+1, and so at some point we will store 4 in ptr. We are
> > allowed to use the value we have read to do this.
>
> Yes.
>
> > We're not allowed to
> > use the value (3) for anything else.
>
> Not relevant, it is a different value (3) that will be used..
>
> >> This is not
> >> UB, any more than i++; is UB.
>
> >> The value yielded by the postfix ++ operator is the value its operand
> >> had at the previous sequence point.
>
> > Yes, it's the 3 we read earlier,
>
> Wrong. The (3) you get here is a completely new and different (3).

This I don't understand. One 3 is the value of ptr at the last
sequence point. The other 3 is also the value of ptr at the last
sequence point. Either we read it twice, or we read it once but use it
for two different purposes - one to work out the new value for ptr,
the other to get the return value of ++ which will be sent to the *
operator. Both approaches seem to contradict the second sentence.

> Just
> as if you have the code...
> =A0 =A0 x =3D 2 * y + 2 * z;
> you have two completely different values which both happen to be 2. The
> first value 2 is the result of the first expression 2 and the second
> value 2 is the result of the second value 2!

But those values are separate! You could amend the code if you wanted
so that one was still 2 and the other was 7. But you can't change the
code of ptr++ so that the value returned is different from the pre-
incremented value of ptr.

> If you meet a pair of twins, do you think they are both the same person,
> or just two people who happen to be identical?
>
> > *but* we are not (apparently) allowed
> > to use it for this.
>
> It's not the same (3) so you are OK :-)
>
> > The standard says "the prior value shall be read
> > only to determine the value to be stored". I presume "stored" here
> > means "stored in &ptr", ie the new value of ptr.
>
> <snip>
>
> You meant sored in ptr, but yes you are correct. Just wrong to think it
> is the same (3).

I meant "written to memory location &ptr", but I think we're in
agreement here.

Hi Richard

Both you and Flash have kindly provided explanations, and the penny
has dropped for at one reader as a result, but I'm afraid I still
don't see it...

On 10 Sep, 22:33, Richard Heathfield <r...@see.sig.invalid> wrote:
> In
> <c4d67d87-6cd4-4513-a38e-e2f289b97...@y42g2000yqb.googlegroups.com>,
>
> Paul N wrote:
> > Richard
>
> > I was puzzled the first time I read the second sentence of the
> > Standard quoted below, and I'm afraid I'm still confused. It seems
> > to make some normal-looking statements, such as the one below, into
> > UB. Presumably I'm reading it wrong. Could you go over it one more
> > time, please?
>
> Context: *p++ =3D var;
>
> Okay, let's do a frinstance. var is 6, okay? (Naturally.)
>
> I'm reluctant to describe p with a number, so let's start off with:
>
> int zog[] =3D { 0xA, 0xB, 0xC, 0xD };
>
> int *p =3D zog;
>
> So p points to zog[0], i.e. the element with value currently 0xA.
>
> Precedence and associativity give us this AST:
>
> =A0 =A0 =A0 =A0=3D
> =A0 =A0 =A0 / \
> =A0 =A0 =A0* =A0 var
> =A0 =A0 /
> =A0 =A0++ (post)
> =A0 /
> =A0p
>
> We start off (okay, take all when-it-happens phrases with a pinch of
> salt, because we might *not* start off...) by accessing p. We do this
> so that we can perform the ++ operation, which will, before the next
> sequence point, increment p so that it points to zog[1], the element
> with value 0xB. We perform the ++ operation, which uses p's value
> (only to determine the value to be stored in p),

Promise? You're not going to use this value for any other purpose?

> and yields a pointer
> value. This pointer value happens to be the same value that p had at
> the previous sequence point,

This still seems to me as if either you are reading it twice, or you
are at least using the value you have read for more than one purpose.
It is not in any way a coincidence that the two values are the same.

> but it is NOT p ITSELF. It's just a
> pointer value. If you like, it's &zog[0].

I appreciate that it is not necessarily the value p has *now*, as p
can be considered to be in a state of flux, as you're about to point
out. But it's the value that p had at the last sequence point. Which
to my mind means that you have read the value of p since that sequence
point to get the value that you are now using. How else can you get
the value?

> So... it is this value, not the current value of p, that is yielded by
> ++. It is necessary to distinguish between them because it is not
> clear at this stage what p's value actually is. It might be &zog[0]
> or it might be &zog[1], and only the optimiser knows which!
>
> After that, it's plain sailing - the value yielded by ++ (which,
> remember, is a different concept to the value of p, even if it
> happens to be the same number right now, which it may or may not be)
> becomes the operand of *, and that gives us the object zog[0], to
> which we assign the value var, and we're done.

Paul N wrote:
) I appreciate that it is not necessarily the value p has *now*, as p
) can be considered to be in a state of flux, as you're about to point
) out. But it's the value that p had at the last sequence point. Which
) to my mind means that you have read the value of p since that sequence
) point to get the value that you are now using. How else can you get
) the value?

By remembering it.  Duh.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

In 
<020b8606-10eb-451d-b168-7483cee920e8@s39g2000yqj.googlegroups.com>, 
Paul N wrote:

<snip>

>> We start off (okay, take all when-it-happens phrases with a pinch
>> of salt, because we might *not* start off...) by accessing p. We do
>> this so that we can perform the ++ operation, which will, before
>> the next sequence point, increment p so that it points to zog[1],
>> the element with value 0xB. We perform the ++ operation, which uses
>> p's value (only to determine the value to be stored in p),
> 
> Promise? You're not going to use this value for any other purpose?

p's value? Promise.

>> and yields a pointer
>> value. This pointer value happens to be the same value that p had
>> at the previous sequence point,
> 
> This still seems to me as if either you are reading it twice,

Nope.

> or you are at least using the value you have read for more than one
> purpose.

Nope.

> It is not in any way a coincidence that the two values are
> the same.

Proof by analogy is fraud. Nevertheless, here is a "proof" by analogy. 
Obviously, it doesn't really prove anything, but it may help you to 
understand the issues more clearly.

Here is a piece of paper. It has stuff written on it. I promise that, 
if I write on this piece of paper, I will do so only once (before the 
next sequence point). If I look at this piece of paper, I will only 
do so to find out what's on it (thus enabling me to write something 
else on it). If I break my promise, the behaviour is undefined.

I now take a photocopy of the piece of paper (and in so doing, I look 
at it, and thus find out what's on it).

Next, I put the original in a special sealed box where it will get 
some new stuff written on it. I can no longer see it. I still have 
the photocopy, though. As long as I don't open the box, my promise is 
secure.

The image on the photocopy is the same as the image on the piece of 
paper before it went into the sealed box. Therefore, I know what 
*was* written on the piece of paper even though I can no longer see 
it and can no longer change it.

What's more, I can use - and even modify - the information written on 
that photocopy, without in any way affecting the information on the 
original.

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

On 11 Sep, 20:39, Richard Heathfield <r...@see.sig.invalid> wrote:
> Proof by analogy is fraud. Nevertheless, here is a "proof" by analogy.
> Obviously, it doesn't really prove anything, but it may help you to
> understand the issues more clearly.
>
> Here is a piece of paper. It has stuff written on it. I promise that,
> if I write on this piece of paper, I will do so only once (before the
> next sequence point). If I look at this piece of paper, I will only
> do so to find out what's on it (thus enabling me to write something
> else on it). If I break my promise, the behaviour is undefined.
>
> I now take a photocopy of the piece of paper (and in so doing, I look
> at it, and thus find out what's on it).
>
> Next, I put the original in a special sealed box where it will get
> some new stuff written on it. I can no longer see it. I still have
> the photocopy, though. As long as I don't open the box, my promise is
> secure.
>
> The image on the photocopy is the same as the image on the piece of
> paper before it went into the sealed box. Therefore, I know what
> *was* written on the piece of paper even though I can no longer see
> it and can no longer change it.
>
> What's more, I can use - and even modify - the information written on
> that photocopy, without in any way affecting the information on the
> original.

That analogy certainly helps clarify the issues. If by "only do so to
find out what's on it (thus enabling me to write something else on
it)" you mean "only do so to enable me to write something
else on it" I would say that you had broken your promise.

For example, I have to fill in a form every year or so to get my name
on the Electoral Roll. I am required by law to fill it in, but the
people receiving it are limited by law on what they can do with the
information. If they were to photocopy the form, and copy the details
from the photocopy into a marketing list, I would say they were
breaking the law, just as if they had copied the details from the
original form.

In 
<2b88d232-6e60-41d3-856b-803149410a5f@k33g2000yqa.googlegroups.com>, 
Paul N wrote:

<snip>
 
> That analogy certainly helps clarify the issues. If by "only do so
> to find out what's on it (thus enabling me to write something else
> on it)" you mean "only do so to enable me to write something
> else on it" I would say that you had broken your promise.

Clearly I /don't/ mean that, because if I did, the analogy would be to 
a language where even a = b; is undefined.

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

On 2009-09-11, Paul N <gw7rib@aol.com> wrote:
> This I don't understand. One 3 is the value of ptr at the last
> sequence point. The other 3 is also the value of ptr at the last
> sequence point. Either we read it twice, or we read it once but use it
> for two different purposes - one to work out the new value for ptr,
> the other to get the return value of ++ which will be sent to the *
> operator. Both approaches seem to contradict the second sentence.

We read it once, to execute the ++ operator.  We have read it only once.
The ++ operator is legit.  As it happens, the ++ operator also yields a
value.  By amazing coincidence, that value is, in this case, the same as
the prior value.

Think about it this way:

	*x++ = 1;
	*++x = 1;

these both work, for the same reason.  It doesn't matter whether you use
the operator whose value happens to be the same *value* as the previous
value of x, or the one whose value happens to be a different value, because
in either case, what you are using for the * operator is not the value of
x, but the value of ++.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On Sep 12, 5:43=A0am, Paul N <gw7...@aol.com> wrote:
> I appreciate that it is not necessarily the value p has *now*, as p
> can be considered to be in a state of flux, as you're about to point
> out. But it's the value that p had at the last sequence point. Which
> to my mind means that you have read the value of p since that sequence
> point to get the value that you are now using. How else can you get
> the value?

It might help you to consider the case:

  *++p

The ideas are exactly the same as for *p++, but
in this example the value read out of 'p' for
the subexpression (++p), and the value that is
the argument of the * operator, are actually
different values, perhaps reducing a cause of
confusion in the example.