sequence points in subexpressions
amit.co...@gmail.com
i = (i, i++, i) + 1;
I am almost convinced that it does not because of the following
reasons
1> the RHS must be evaluated before a value can be stored in i
2> evaluation of RHS does not invoke UB due to the sequence points
introduced by comma operator
Correct me if i an wrong!
Thanks
Richard
What do you think the answer is?
i=i+2 ?
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
amit.co...@gmail.com
I am sure that it's well defined.
I am quoting someone's comment/view on that statement.
> Yes the sequence point after i++ completes all side effects before it, but there is nothing that > stops the assignment side effect overlapping with the side effect of i++. The underlying problem > is that the side effect of an assignment is not specified to happen after or before the
> evaluation of both operands of the assignment, and so sequence points cannot do anything with
> regard to protecting this: Sequence points induce a partial order: Just because there is a
> sequence point after and before i++ doesn't mean all side effects are sequenced with regard to
> it.
I was trying to comprehend it.
I am not *100%* sure that what he said is wrong.
So any comments on it(the comment)?
pete
> Does the statement given below invoke undefined behavior?
> i = (i, i++, i) + 1;
>
> I am almost convinced that it does not because of the following
> reasons
>
> 1> the RHS must be evaluated before a value can be stored in i
You would think so but,
the evaluation of an expression also includes side effects,
and the side effects of the evaluation of the right operand
do not have to occur
before the assignment operation on the left operand.
--
pete
Richard
What side affects would you expect from the right hand side, keeping in
mind the sequence points?
mohangupta13
> pete <pfil...@mindspring.com> writes:
With due regard to everyone's comments , can anyone please explicitly
say whether the above statement is actually UD or not ? I am not able
to get this from the above comments .
Thanks
Mohan
Nick
> On Dec 13, 5:05 pm, Richard <rgrd...@gmail.com> wrote:
>> pete <pfil...@mindspring.com> writes:
>> > amit.codenam...@gmail.com wrote:
>> >> Does the statement given below invoke undefined behavior?
>> >> i = (i, i++, i) + 1;
>>
>> >> I am almost convinced that it does not because of the following
>> >> reasons
>>
>> >> 1> the RHS must be evaluated before a value can be stored in i
>>
>> > You would think so but,
>> > the evaluation of an expression also includes side effects,
>> > and the side effects of the evaluation of the right operand
>> > do not have to occur
>> > before the assignment operation on the left operand.
>>
>> What side affects would you expect from the right hand side, keeping in
>> mind the sequence points?
>>
>
> With due regard to everyone's comments , can anyone please explicitly
> say whether the above statement is actually UD or not ? I am not able
> to get this from the above comments .
I often wonder why anyone cares about this sort of statement. It
doesn't look the sort of thing that might be produced by computer
generated code, and it doesn't look the thing you'd actually want to
write into a program. If it's that borderline and you'd never need it,
why does it actually matter, other than as a sort of C language sudoku.
--
Online waterways route planner: http://canalplan.org.uk
development version: http://canalplan.eu
Seebs
> With due regard to everyone's comments , can anyone please explicitly
> say whether the above statement is actually UD or not ? I am not able
> to get this from the above comments .
I am honestly not sure.
I think it is, but... I don't know. Here's the case that convinced me:
a[i] = (1, i++, 1);
It seems clear to me that there's a real-world risk that the evaluation of
i on the left is at risk of occurring during the evaluation of the RHS.
So I don't think there's a sequence point between the sides.
More importantly:
1. You don't need to do that.
2. Even if it's not undefined behavior, it's the kind of case where compilers
might have unexpected bugs.
3. So don't do that, then. Just write out what you mean.
In most of the "interesting" edge cases, the right answer is not to go there.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Kenny McCormack
Nick <3-no...@temporary-address.org.uk> wrote:
...
>I often wonder why anyone cares about this sort of statement. It
>doesn't look the sort of thing that might be produced by computer
>generated code, and it doesn't look the thing you'd actually want to
>write into a program. If it's that borderline and you'd never need it,
>why does it actually matter, other than as a sort of C language sudoku.
Indeed. Well put. ITA.
But the point is that that is precisely the stock-in-trade of this
newsgroup. As I have shown many times, it is not possible to post
anything to this newsgroup, that will meet the generally accepted
standards of "appropriateness", that is not either a) a topicality flame
(gotta love them!) or b) language lawyering, of the type that is of no
interest to the vast majority of working C programmers.
Your post hits the nail on the head as to the sort of thing that people
like Kiki, et al, just salivate over, but the rest of us find dull and
uninteresting at best, and downright offensive at worst.
Flash Gordon
> On 2009-12-13, mohangupta13 <mohang...@gmail.com> wrote:
>> With due regard to everyone's comments , can anyone please explicitly
>> say whether the above statement is actually UD or not ? I am not able
>> to get this from the above comments .
For context, the statement was
i = (i, i++, i) + 1;
> I am honestly not sure.
>
> I think it is, but... I don't know.
I think it isn't UB.
> Here's the case that convinced me:
>
> a[i] = (1, i++, 1);
>
> It seems clear to me that there's a real-world risk that the evaluation of
> i on the left is at risk of occurring during the evaluation of the RHS.
> So I don't think there's a sequence point between the sides.
That example is different because i is used on the left to determine the
object to be stored, where as in the original it is merely the object in
which the result will be stored.
> More importantly:
> 1. You don't need to do that.
> 2. Even if it's not undefined behavior, it's the kind of case where compilers
> might have unexpected bugs.
> 3. So don't do that, then. Just write out what you mean.
>
> In most of the "interesting" edge cases, the right answer is not to go there.
That I definitely agree with. I would reject any code like this I came
across in a code review.
--
Flash Gordon
Chad
> >> With due regard to everyone's comments , can anyone please explicitly
> >> say whether the above statement is actually UD or not ? I am not able
> >> to get this from the above comments .
>
> For context, the statement was
> i = (i, i++, i) + 1;
>
> > I am honestly not sure.
>
> > I think it is, but... I don't know.
>
> I think it isn't UB.
>
> > Here's the case that convinced me:
>
> > a[i] = (1, i++, 1);
>
> > It seems clear to me that there's a real-world risk that the evaluation of
> > i on the left is at risk of occurring during the evaluation of the RHS.
> > So I don't think there's a sequence point between the sides.
>
> That example is different because i is used on the left to determine the
> object to be stored, where as in the original it is merely the object in
> which the result will be stored.
>
Why wouldn't the result get store in a[i] = (1, i++, 1); ?
Beej Jorgensen
> Does the statement given below invoke undefined behavior?
> i = (i, i++, i) + 1;
I think these are the sequence points:
i = (i , i++ , i) + 1 ;
1 2 3
(1 and 2 at the end of the first operand to a comma operator, and 3 at
the end of a full expression.) So I believe what we have is this:
i [i == 0, let's say]
[sequence point 1]
i++ [i == 1 by the next sequence point]
[sequence point 2]
i = i + 1 [i == 2 by the next sequence point]
[sequence point 3]
I don't see anything here that violates C99 6.5p2, so I'm going to bet
that it's OK. gcc offers no applicable complaints* at full-warnings,
and outputs 2 in the above example.
(And I'd like to buy insurance on that bet--I'm pushing the bounds of my
knowledge, here.)
-Beej
* gcc does warn that the leftmost i in (i, i++, i) has no effect.
James Dow Allen
> I think it isn't UB.
I'm not sure. In the simple case:
i = (1, i++, i) + 1;
It may be hard to imagine how the C system
could go wrong, but one might be able to imagine
some cache-speeding trick that assumes it
won't encounter this code (or can do what it wants
with it, if marked UB in The Standard).
For those who think commas are permitted, what about:
*(p += i, ++i, p += i) = j++, ++j, j;
No problem right?
The commas at left separate left-side sequence points,
and commas at right separate (order) a different
set of sequence points. We end up, in effect with
i += 1, *(p += i+i-1) = j += 2;
What do we know about *which* sequence points are
reached first, right-side vs left-side, or can they
be interelaved?
Now what about:
*(p += i, ++i, p += i) = i++, ++i, i;
Definitely UB-lookingish.
> > In most of the "interesting" edge cases, the right answer is not to go there.
> .
> That I definitely agree with. I would reject any code like this I came
> across in a code review.
While certainly this code would be rejected,
it *is* good to look at border cases.
On Dec 13, 9:30 pm, Nick <3-nos...@temporary-address.org.uk> wrote:
> I often wonder why anyone cares about this sort of statement. It
> doesn't look the sort of thing that might be produced by computer
> generated code, and it doesn't look the thing you'd actually want to
> write into a program. If it's that borderline and you'd never need it,
> why does it actually matter, other than as a sort of C language sudoku.
I argued much like this 5 weeks back in a somewhat similar thread and
was rebuked. And the old thread was the same old silly expression
designed
to provoke UB, while OP's query *does* represent a defining corner-
case.
James Dow Allen
Beej Jorgensen
Just because the right side of the assignment is in parentheses and uses
the comma operator doesn't mean the subexpression in left side can't be
evaluated at the same time. (C99 6.5p3)
(1, i++, 1) definitely has to be evaluated before the assignment, but
the a+i subexpression of *(a+i) (same as a[i]) can be evaluated before
or after (1, i++, 1).
I don't think this example runs afoul of 6.5p2, which forbids things
like a[i++]=i, because of the sequence point after i++. ...?
-Beej
pete
> pete <pfi...@mindspring.com> writes:
>
>
>>amit.co...@gmail.com wrote:
>>
>>>Does the statement given below invoke undefined behavior?
>>>i = (i, i++, i) + 1;
>>>
>>>I am almost convinced that it does not
It does.
> because of the following
>>>reasons
>>>
>>>1> the RHS must be evaluated before a value can be stored in i
That's wrong.
>>
>>You would think so but,
>>the evaluation of an expression also includes side effects,
>>and the side effects of the evaluation of the right operand
>>do not have to occur
>>before the assignment operation on the left operand.
>
>
> What side affects would you expect from the right hand side, keeping in
> mind the sequence points?
>
The side effect from the increment operator.
The sequence points from the comma operator are not relevant
because there is no sequence point between the evaluation
of the right and left operands of the assignment operator.
If the right operand of the assignment opeartor is evaluated first,
then there shouldn't be any problem with
i = i++;
but there is a problem.
Assignment is not a sequence point.
--
pete
Flash Gordon
> On Dec 14, 2:20 am, Flash Gordon <s...@spam.causeway.com> wrote:
>> Seebs wrote:
>>> I think it is UB.
>> I think it isn't UB.
>
> I'm not sure. In the simple case:
> i = (1, i++, i) + 1;
> It may be hard to imagine how the C system
> could go wrong, but one might be able to imagine
> some cache-speeding trick that assumes it
> won't encounter this code (or can do what it wants
> with it, if marked UB in The Standard).
Certainly if it is UB such assumptions can be made, but it is?
There is a sequence point between the evaluation of i++ and the
evaluation of i to its right, and it is the result of that i which is
yielded by the comma operator and then has 1 added to it before being
assigned to i. So, the sequence point of the comma operator is before
the assignment side effect of the equals operator.
> For those who think commas are permitted, what about:
> *(p += i, ++i, p += i) = j++, ++j, j;
> No problem right?
> The commas at left separate left-side sequence points,
> and commas at right separate (order) a different
> set of sequence points. We end up, in effect with
> i += 1, *(p += i+i-1) = j += 2;
>
> What do we know about *which* sequence points are
> reached first, right-side vs left-side, or can they
> be interelaved?
They can.
> Now what about:
> *(p += i, ++i, p += i) = i++, ++i, i;
> Definitely UB-lookingish.
Yes, because there here i is not simply the object to which the right
hand side of the equals operator is being assigned.
>>> In most of the "interesting" edge cases, the right answer is not to go there.
>> .
>> That I definitely agree with. I would reject any code like this I came
>> across in a code review.
>
> While certainly this code would be rejected,
> it *is* good to look at border cases.
Well, it doesn't particularly bother me.
> On Dec 13, 9:30 pm, Nick <3-nos...@temporary-address.org.uk> wrote:
>> I often wonder why anyone cares about this sort of statement. It
>> doesn't look the sort of thing that might be produced by computer
>> generated code, and it doesn't look the thing you'd actually want to
>> write into a program. If it's that borderline and you'd never need it,
>> why does it actually matter, other than as a sort of C language sudoku.
>
> I argued much like this 5 weeks back in a somewhat similar thread and
> was rebuked. And the old thread was the same old silly expression
> designed
> to provoke UB, while OP's query *does* represent a defining corner-
> case.
Ah well, you can't expect to always get the same answer!
--
Flash Gordon
Kaz Kylheku
> Richard wrote: >> pete <pfi...@mindspring.com> writes:
>>
>>
>>>amit.co...@gmail.com wrote:
>>>
>>>>Does the statement given below invoke undefined behavior?
>>>>i = (i, i++, i) + 1;
>>>>
>>>>I am almost convinced that it does not
>
> It does.
>
>> because of the following
>>>>reasons
>>>>
>>>>1> the RHS must be evaluated before a value can be stored in i
>
> That's wrong.
>
>>>
>>>You would think so but,
>>>the evaluation of an expression also includes side effects,
>>>and the side effects of the evaluation of the right operand
>>>do not have to occur
>>>before the assignment operation on the left operand.
>>
>>
>> What side affects would you expect from the right hand side, keeping in
>> mind the sequence points?
>>
>
> The side effect from the increment operator.
The value being stored in the assignment is that of the rightmost
operand of the comma expression. The computation of the rightmost
operand follows a sequence point. So the modification of i in the
assignment is well-ordered with regard to the prior side effects
in the comma expression.
> The sequence points from the comma operator are not relevant
> because there is no sequence point between the evaluation
> of the right and left operands of the assignment operator.
There is a data flow dependency, however. The value cannot be
stored before it is computed.
In the expression
i = (i, i++, i) + 1;
^
the value to be stored is derived from the value of the expression
denoted by the caret, by adding 1.
The denoted expression is the right operand of a comma, so its
evaluation is delayed until prior side effects have settled.
The sequencing in the comma operator, plus the dataflow dependency
in the assigment, add up to well-defined behavior.
Keith Thompson
The problem with
i = i++;
is that the side effect of the "++" can happen any time before
the end of the statement.
In
i = (i, i++, i) + 1;
let's consider the subexpression
(i, i++, i)
Here, the side effect of the "++" must happen before the next sequence
point, which occurs, not at the end of the statement, but at the comma
operator. The entire subexpression yields the value of i after it's
been incremented, and the value of i is updated before the
subexpression completes.
Looking at the full expression:
i = (i, i++, i) + 1;
I argue that adding 1 to the result of the subexpression and
assigning that to i doesn't introduce any undefined behavior.
The assignment cannot modify i until the RHS has been evaluated.
The RHS cannot yield a result until after the side effect of the
increment has occurred.
So you could at least have a reasonable and consistent set of rules
that makes "i = i++" undefined but makes "i = (i, i++, i) + 1" well
defined.
Whether C99 actually has such rules is another question. N1256 says:
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 *think* this makes the expression in question well defined, but
I'm not certain.
The C201X drafts (the latest is
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1425.pdf>)
use different wording in this area, referring to operations being
"sequenced before" or "sequenced after" other operations. The new
wording might make this case clearer (I'm too lazy to check at
the moment).
--
Keith Thompson (The_Other_Keith) ks...@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"
Beej Jorgensen
> i = (i, i++, i) + 1;
>
> I am almost convinced that it does not because of the following
> reasons
Ok, I've been poring over the latest draft, which takes a better stab at
all of this. I still don't really know the answer, but here's more
stuff according to that draft. (I stared at C99 today trying to coax
the real answer out of it, but I was just getting unhappy with the model
which didn't seem to want to spit it out. C09 is more complex with some
abstractions that I think help clarify these issues.)
Comments welcomed on everything I've written here. Please be aware that
this is my understanding of a document that I just looked at for the
first time today and is in no way necessarily correct or definitive.
> 1> the RHS must be evaluated before a value can be stored in i
It's a little bit nuanced, because "evaluation" is two things:
# Evaluation of an expression in general includes both value
# computations and initiation of side effects. [5.1.2.3p2]
Note that it's not "resolution" of side effects (which don't necessarily
occur until a sequence point.)
With respect to expressions:
# The value computations of the operands of an operator are sequenced
# before the value computation of the result of the operator. [6.5p1]
So, yes, the value computation must be done before the assignment, but
not necessarily the resolution of side effects.
In terms of sequencing of operations:
# Given any two evaluations A and B, if A is sequenced before B, then
# the execution of A shall precede the execution of B. [...] If A is
# not sequenced before or after B, then A and B are unsequenced.
# [5.1.2.3p3]
Remember, we're talking about "evaluations", which does not necessarily
include resolution of side effects.
And how this relates to expressions (this is *the* paragraph that lays
down the law):
# 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. [6.5p2]
So back to the example:
i = (i, i++, i) + 1;
We have two side effects in the assignment and the ++. The question is,
are they sequenced?
Well, we know that the value computations of the operands to + are
sequenced before the value computation of the result of +. So the value
of 1 and the value of (i,i++,i) are computed before the result of + is.
What of the comma operator?
# The left operand of a comma operator is evaluated as a void
# expression; there is a sequence point between its evaluation and that
# of the right operand. Then the right operand is evaluated; the result
# has its type and value. [6.5.17p2]
What is a sequence point?
# The presence of a sequence point between the evaluation of expressions
# A and B implies that every value computation and side effect
# associated with A is sequenced before every value computation and side
# effect associated with B. [5.1.2.3p3]
So now we get our forced sequencing of side effects, as well. With the
expression (i,i++,i), the side effect of i++ must be complete before the
value of the expression (namely i) is can be computed. And the value of
the expression must be computed before it can subsequently be used by +.
And +'s value must be computed before the assignment can occur:
# The side effect of updating the stored value of the left operand is
# sequenced after the value computations of the left and right operands.
# [6.5.16p3]
Working backward:
o For the assignment side effect to occur, the value computations of
both operands of the assignment must be complete.
o For the value computations on the right side of the assignment to be
complete, the value computations of the + operator's operands have
to be complete.
o For the value computation of (i,i++,i) to be complete, i++'s side
effects must be complete.
And so, I think, the side effect of i++ is sequenced before the side
effect of i=, and so in this case is not undefined behavior.
Some counter cases:
i = i++;
While the sequence of value computations is defined for i=i++, the
side effects are unsequenced, and so it is undefined behavior.
|----- A ----| |----- B ----|
k = (i, i /= 3, i) + (i, i *= 5, i); // "please...kill me..."
In this case, the value computations of both subexpressions A and B
must be complete before +, and therefore, by the previous pages of
arguments, the side effects of i/=3 and i*=5 must also be complete
before the +.
And, therefore, the side effects of i/=3 and i*=5 must also be
complete before the result of the value computation of + is finally
assigned into k.
However, the two subexpressions A and B are unsequenced relative to
one another and both modify the same object, and so the behavior is
undefined.
Do I believe it myself? I don't even know anymore. :)
What do you think, folks?
-Beej
(Remember: this analysis is based on the draft, not the Standard. I'm
just presuming they're going to try to keep it basically compatible.)
Ben Bacarisse
<snip>
> Ok, I've been poring over the latest draft, which takes a better stab at
> all of this.
I find all this wording much clearer than the old description. The
trouble I always had with the old wording is that sequence points are
points in the program text, but the restriction on what is permitted
is worded in terms of temporal ordering of actual events. When the
C99 standard says, in effect, that the order of execution is
unspecified, you are left trying to relate possible execution paths
though the text so as to get all the event orderings that are possible
to see if any violate the constraint.
This new wording greatly simplifies the task of ascertaining the
permitted orderings. I like it much better.
> Working backward:
>
> o For the assignment side effect to occur, the value computations of
> both operands of the assignment must be complete.
>
> o For the value computations on the right side of the assignment to be
> complete, the value computations of the + operator's operands have
> to be complete.
>
> o For the value computation of (i,i++,i) to be complete, i++'s side
> effects must be complete.
>
> And so, I think, the side effect of i++ is sequenced before the side
> effect of i=, and so in this case is not undefined behavior.
I agree. I also agree (for what it is worth) that it is not undefined
even using the current text of the standard.
<snip>
--
Ben.
pete
No.
The side effects of the increment operator
are not needed for the dataflow dependency.
The value of the right operand of the assignment operator
can be calculated without any side effects taking place;
It will be equal to (i + 2).
The data must be calculated first,
but the verb "evaluate"has two parts,
1 value calulations
2 side effects
and in this case, the side effects are not needed
for the data calculations
and there's no reason why they can't take place after
the assignment to the left operand of the assignment operator.
Sequence points are only defined by
when the side effects of an evaluation take place,
not the data calculations.
(p = p -> next = q)
means the exact same thing as
(p = (p -> next = q))
But the side effect of evaluating (p -> next = q)
does not have to take place before the update of p.
--
pete
pete
> o For the value computation of (i,i++,i) to be complete, i++'s side
> effects must be complete.
I disagree.
I know that the value of (i,i++,i) is one greater
than the original value of (i).
I computed that without accomplishing any side effects.
> And so, I think, the side effect of i++ is sequenced before the side
> effect of i=, and so in this case is not undefined behavior.
--
pete
Keith Thompson
> Beej Jorgensen wrote:
>
>> o For the value computation of (i,i++,i) to be complete, i++'s side
>> effects must be complete.
>
> I disagree.
> I know that the value of (i,i++,i) is one greater
> than the original value of (i).
> I computed that without accomplishing any side effects.
Yes, but the side effect of the ++ *must* take place (i.e., the
value of i must actually be updated) before the next sequence point.
In this case, the next sequence point is the comma operator.
Once again, the statement in question is
i = (i, i++, i) + 1;
The side effect of the "++" must occur before the evaluation of the
``i'' after the second comma operator. The addition (``+ 1'') must
occur after that evaluation of ``i''. The evaluation of the RHS
depends on the result of the addition, so the evaluation of the RHS
must occur after the side effect of the "++". The side effect of
the assignment operator must occur after the evaluation of the RHS.
(And, of course, the question is irrelevant in real life, because
the code would not survive review -- unless it's part of a compiler
test suite.)
Michael Foukarakis
> Beej Jorgensen wrote:
> > o For the value computation of (i,i++,i) to be complete, i++'s side
> > effects must be complete.
>
> I disagree.
> I know that the value of (i,i++,i) is one greater
> than the original value of (i).
> I computed that without accomplishing any side effects.
The postfix increment operator's side effect is incrementing its
operand by 1. That's what you "computed". Get it now? Basic
comprehension OK?
Beej's post is great and very informative. The OP's construct doesn't
invoke UB.
Beej Jorgensen
> Beej Jorgensen wrote:
>
>> o For the value computation of (i,i++,i) to be complete, i++'s side
>> effects must be complete.
>
> I disagree.
> I know that the value of (i,i++,i) is one greater
> than the original value of (i).
> I computed that without accomplishing any side effects.
Then I think you skipped over a sequence point without performing every
value computation and side effect associated with subexpression i++, in
violation of 5.1.2.3p3:
# The presence of a sequence point between the evaluation of expressions
# A and B implies that every value computation and side effect
# associated with A is sequenced before every value computation and side
# effect associated with B.
But you're arguing the side effects don't necessarily take place at the
sequence point, is that right?
-Beej
Eric Sosman
> James Dow Allen wrote:
>> On Dec 14, 2:20 am, Flash Gordon <s...@spam.causeway.com> wrote:
>>> Seebs wrote:
>>>> I think it is UB.
>>> I think it isn't UB.
>>
>> I'm not sure. In the simple case:
>> i = (1, i++, i) + 1;
>> It may be hard to imagine how the C system
>> could go wrong, but one might be able to imagine
>> some cache-speeding trick that assumes it
>> won't encounter this code (or can do what it wants
>> with it, if marked UB in The Standard).
>
> Certainly if it is UB such assumptions can be made, but it is?
> There is a sequence point between the evaluation of i++ and the
> evaluation of i to its right, and it is the result of that i which is
> yielded by the comma operator and then has 1 added to it before being
> assigned to i. So, the sequence point of the comma operator is before
> the assignment side effect of the equals operator.
The value of the parenthesized sub-expression is the
value of `i' after incrementation, yes. But where is it
written that the sub-expression's value must be determined
by actually reading it from `i'? If an optimizing compiler
knew that `i' was 42 before the line in question, could it
not replace the assignment with `i=44', with the `i++'
happening at some undetermined moment?
--
Eric Sosman
eso...@ieee-dot-org.invalid
Michael Tsang
Hash: SHA1
amit.co...@gmail.com wrote:
> Does the statement given below invoke undefined behavior?
> i = (i, i++, i) + 1;
>
> I am almost convinced that it does not because of the following
> reasons
>
> 1> the RHS must be evaluated before a value can be stored in i
> 2> evaluation of RHS does not invoke UB due to the sequence points
> introduced by comma operator
>
> Correct me if i an wrong!
>
> Thanks
I don't think it is UB. Let SQ 0 be the last sequence point before the full
expression, SQ 1 be the sequence point between i and i++, SQ 2 be the
sequence point between ++i and i, SQ 3 be the sequence point the the end of
the full expression. Because the right hand side must be read in order to
determine the value stored, the = operator must be evaluated between SQ 2
and SQ 3 but in the right hand side, i++ is done between SQ 1 and SQ 2 so
there is no UB.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAksmTKEACgkQG6NzcAXitM9oxgCfTCFGZxWjIl4iJP/5YYlLOgkq
hVgAnjmhyxO6RMYmsa6WztW65CNBlyHC
=VY9x
-----END PGP SIGNATURE-----
Kaz Kylheku
> No.
> The side effects of the increment operator
> are not needed for the dataflow dependency.
That is true in general, but not in this specific expression.
The key here is that the comma operator imposes the side effect barrier.
> The value of the right operand of the assignment operator
> can be calculated without any side effects taking place;
> It will be equal to (i + 2).
You are gapingly overlooking the fact that algebraic evaluation
shortcuts are optimizations which are only permitted if they don't break
the abstract semantics.
> Sequence points are only defined by
> when the side effects of an evaluation take place,
> not the data calculations.
That is false. A sequence point establishes not only that prior side
effects have settled, but that the next evaluation has not yet started.
I.e. if the prior evaluation has the side effect of modifying X, and the
next evaluation accesses X (a data calculation), then this means that
the side effect of X is settled, and the next evaluation will use the
new, updated, stable value of X.
> (p = p -> next = q)
>
> means the exact same thing as
>
> (p = (p -> next = q))
>
> But the side effect of evaluating (p -> next = q)
> does not have to take place before the update of p.
This is different because no operator is used in this expression which
has sequencing properties.
Since it does not contain any, this example you have given can be used
to neither support nor refute any of your claims about the properties of
sequence points.
Kaz Kylheku
>
>> o For the value computation of (i,i++,i) to be complete, i++'s side
>> effects must be complete.
>
> I disagree.
> I know that the value of (i,i++,i) is one greater
> than the original value of (i).
> I computed that without accomplishing any side effects.
What you are describing is the existence of an algebraic shortcut,
which is an optimization.
Remember, that the actual machine can take arbitrary optimizations
in computing the visible behavior of the program, but the results have
to be like what the abstract machine would have computed.
The abstract machine requires adherence to sequence points.
Optimizations can discard sequence points only when it makes no
difference to the computed value, or externally visible behavior.
pete
No.
I'm saying that the word "evaluation" includes side effects,
and I'm saying that value of an expression can be determined and used
prior to the evaluation of that expression being completed.
--
pete
Keith Thompson
Consider:
int i = 0;
int j = 0;
i ++;
j = i;
I can determine the value of the expression ``i'' on line 4
(it's 1) without completing the evaluation of ``i ++'' on line 3.
Nevertheless, the side effect of the "++" must occur before the
side effect of the "=" on line 4.
A compiler may generate code that performs the operations in a
different order, or that omits some operations altogether, but any
such optimization cannot produce visible behavior outside the range
of permitted behaviors of the abstract machine. In particular,
optimization cannot introduce undefined behavior when the behavior
was well defined in the first place.
I think you'll agree that the behavior of my 4-line snippet
above is well defined. I argue that the behavior of
i = (i, i++, i) + 1;
is well defined for the same reason: the sequence points impose
requirements on when the side effects take place, and limit the
optimizer's options to rearrange operations.
[A request: when replying in this thread, please include the original
statement we're discussion.]
Antoninus Twink
> If it's that borderline and you'd never need it, why does it actually
> matter, other than as a sort of C language sudoku.
*ding*
It seems a light has come on.
Kenneth Brody
>
> reasons
>
> 1> the RHS must be evaluated before a value can be stored in i
> 2> evaluation of RHS does not invoke UB due to the sequence points
> introduced by comma operator
>
> Correct me if i an wrong!
I agree with the posters elsethread that say this is well-defined, because
of the sequence point at the comma operators.
Let's take a slightly contrived, but less "silly" example:
extern foo *do_foo(foo *);
extern foo *pt;
...
pt = do_foo(pt++);
The sequence point at the function call guarantees that the side-effects of
"pt++" will have been completed before the function call, and therefore
before the assignment. This is no different, from a side-effects and
sequence-point point of view than:
pt = ( pt, pt++, pt );
It is irrelevant that the assignment operator is not a sequence point,
because the order of evaluation has no bearing on this particular case.
Now, had the original example used "i" instead of "1" outside the parens:
i = (i, i++, i) + i;
then this would be a totally different question. I'm not certain if this
constitutes "undefined" or "unspecified". However, given the same sequence
points because of the comma operators, I would have to lean towards
"unspecified".
--
Kenneth Brody
Kenneth Brody
> Beej Jorgensen wrote:
>
>> o For the value computation of (i,i++,i) to be complete, i++'s side
>> effects must be complete.
>
> I disagree.
> I know that the value of (i,i++,i) is one greater
> than the original value of (i).
> I computed that without accomplishing any side effects.
But, in order for the result to be "one greater than the original value of
(i)", the side effect of incrementing "i" must have taken place before
evaluating the lone "i" which follows.
You just disproved yourself. :-)
QED.
[...]
--
Kenneth Brody
Chad
How can you determine the value of the expression 'i' on line 4
without completing the evaluation of 'i++' on line 3?
Beej Jorgensen
It depends on if by "completing the evaluation of", you mean that side
effects have been resolved, or if they are still pending and merely the
value calculation has been performed.
Because maybe the side effect of storing the result of i++ in i hasn't
been done yet, even though the answer is known. The side effect of
storing the result must merely happen before the next sequence point.
Here's some example fake "assembly" of (i,i++,i) starting with i = 3490
that does this:
; I think this example violates the
; Standard by ignoring a sequence point
i = 3490
i_inc = i + 1
result = i_inc ; we've calculated the result before storing it
i++ ; now we store it
Where I'm differing with Pete is that I think there's a sequence point after
i++, and therefore the side effect must take place by then:
i = 3490
;; == sequence point ==
i_inc = i + 1
i++ ; now we store it because of the seq point
;; == sequence point ==
result = i_inc
;; == sequence point ==
Take special note of that last line there. It could just as well have
been:
result = i
and had it work. This is the bit Pete is saying that I do agree with.
-Beej
Beej Jorgensen
> Beej Jorgensen wrote:
>> But you're arguing the side effects don't necessarily take place at the
>> sequence point, is that right?
>
> No.
Ok, so you are saying that side effects do necessarily take place at the
sequence point.
And do you agree that the comma in the subexpression i++,i is a sequence
point?
> I'm saying that the word "evaluation" includes side effects,
It includes "the initiation of side effects" [201x 5.1.2.3p2]
-Beej
Keith Thompson
>> Consider:
>>
>> int i = 0;
>> int j = 0;
>> i ++;
>> j = i;
>>
>> I can determine the value of the expression ``i'' on line 4
>> (it's 1) without completing the evaluation of ``i ++'' on line 3.
>> Nevertheless, the side effect of the "++" must occur before the
>> side effect of the "=" on line 4.
>
> How can you determine the value of the expression 'i' on line 4
> without completing the evaluation of 'i++' on line 3?
By analyzing the code. We know that the value that will be stored in
j is 1; if we can figure it out, so can the compiler.
Consider this complete program:
include <stdio.h>
int main(void)
{
int i = 0;
int j = 0;
i ++;
j = i;
printf("i = %d, j = %d\n", i, j);
return 0;
}
The compiler is free to replace the assignment ``j = i;'' with the
equivalent of ``j = 1;'', or even to eliminate j altogether and
replace the printf call with ``puts("i = 1, j = 1")''. What it
*can't* do is generate code that produces output other than
i = 1, j = 1
In particular, if it generates code for "j = i;" that actually reads i
and updates j, it can't postpone the side efect of the "++" operator
so it occurs after the assignment.
Beej Jorgensen
> The value of the parenthesized sub-expression is the
> value of `i' after incrementation, yes. But where is it
> written that the sub-expression's value must be determined
> by actually reading it from `i'?
I don't think that's written--I think it can get the calculated value of
i++ from wherever it wants, but I think it is written that the side
effect of i++ (i.e. the modification of i) must occur before the
rightmost i is evaluated in the subexpression i,i++:
[C99 5.1.2.3p2]
# At certain specified points in the execution sequence called sequence
# points, all side effects of previous evaluations shall be complete and
# no side effects of subsequent evaluations shall have taken place.
[C99 6.5.1.7p2]
# The left operand of a comma operator is evaluated as a void
# expression; there is a sequence point after its evaluation.
I see how it's theoretically possible to perform this calculation:
i = (i, i++, i) + 1
without applying the side effect of storing i+1 in i, but I don't see
how it would be *legal* to do so under the Standard.
> If an optimizing compiler knew that `i' was 42 before the line in
> question, could it not replace the assignment with `i=44', with the
> `i++' happening at some undetermined moment?
In a world without sequence points, I'd totally allow i++ to store the
result in i at some undetermined moment, but the sequence point at the
comma forces the side effect to take place at that particular moment.
(Perhaps the side effect hasn't taken place in "machine code reality",
but it must have taken place in "C code reality".)
Of course, if an optimizing compiler can determine that none of the side
effects or calculations will be visible, it is free to optimize the
entire expression away (spelled out in C99 5.1.2.3p3). But I figure
that since we're discussing it, this particular optimization has not
occurred in this case. :)
-Beej
Johannes Schaub (litb)
> Does the statement given below invoke undefined behavior?
> i = (i, i++, i) + 1;
>
> I am almost convinced that it does not because of the following
> reasons
>
> 1> the RHS must be evaluated before a value can be stored in i
> 2> evaluation of RHS does not invoke UB due to the sequence points
> introduced by comma operator
>
Hello there! I'm the evil guy that stated it is UB in C. After reading
analysis of all you, i agree that this is not undefined behavior in C1x
(great work @ Beej Jorgensen !)
But i still think it is UB in C99. The additional requirements about value
computations are missing from C99 and so the "Between the previous and next
sequence point an object shall have its stored value modified at most once
by the evaluation of an expression." seems to render behavior UB.
In C99 it doesn't matter whether the assignment to i needs to compute a
value first. Merely the missing sequence point between the assignment and
the "i++" is enough to render behavior UB by the above quote.
Of course, my analysis might be too simple and miss some important points.
Beej Jorgensen
> But i still think it is UB in C99. The additional requirements about value
> computations are missing from C99 and so the "Between the previous and next
> sequence point an object shall have its stored value modified at most once
> by the evaluation of an expression." seems to render behavior UB.
I'm still not sure because I'm not sure where the "next sequence point"
is in C99.
A B C D
| | | |
i = (i, i++, i) + 1
i is modified twice between A and D, which causes UB by your above cite.
But what of sequence point C? Does it not count?
I can't help but feel that C99 is missing a needed dimension in the
model, and 201x is addressing this. (Though it might have been a
necessary addition due to the threading stuff [5.1.2.4 "Multi-threaded
executions and data races"] which heavily relies on sequencing side
effects.)
-Beej
Johannes Schaub (litb)
> On 12/14/2009 02:07 PM, Johannes Schaub (litb) wrote:
>> But i still think it is UB in C99. The additional requirements about
>> value computations are missing from C99 and so the "Between the previous
>> and next sequence point an object shall have its stored value modified at
>> most once by the evaluation of an expression." seems to render behavior
>> UB.
>
> I'm still not sure because I'm not sure where the "next sequence point"
> is in C99.
>
> A B C D
> | | | |
> i = (i, i++, i) + 1
>
> i is modified twice between A and D, which causes UB by your above cite.
> But what of sequence point C? Does it not count?
>
I think "previous and next" means the sequence point prior to the point of
execution in the execution sequence, and next to the point of execution. In
the UB scenario, the assignment happens between B and C. If it happens
between C and D, behavior is not UB. Where it happens is unspecified.
I share your worry as i don't know what is meant in 6.5.16/3 by "The side
effect of updating the stored value of the left operand shall
occur between the previous and the next sequence point.". In general, i
think sequence points are not at certain places in code, but in the
execution of it (in describing the comma operator, for instance, C99 says
"The left operand of a comma operator is evaluated as a void expression;
there is a sequence point after its evaluation." - it doesn't say "there is
a sequence point after the first operand.". But then in the description of
the assignment expression, it appears to refer to the "enclosing" full
expression sequence points - weird!
> I can't help but feel that C99 is missing a needed dimension in the
> model, and 201x is addressing this. (Though it might have been a
> necessary addition due to the threading stuff [5.1.2.4 "Multi-threaded
> executions and data races"] which heavily relies on sequencing side
> effects.)
>
Same here :)
Peter Nilsson
> > > Beej Jorgensen wrote:
> > > > o For the value computation of (i,i++,i) to be
> > > > complete, i++'s side effects must be complete.
> > >
> > > I disagree.
> > > I know that the value of (i,i++,i) is one greater
> > > than the original value of (i).
> > > I computed that without accomplishing any side
> > > effects.
> >
> > take place at the sequence point, is that right?
>
> No.
> I'm saying that the word "evaluation" includes side
> effects, and I'm saying that value of an expression can
> be determined and used prior to the evaluation of that
> expression being completed.
Consider...
int f(int i) { printf("%d\n", i); return i }
int i = 42;
i = f(i) + 1;
An implementation could deduce that i ends up with the value
of one more than it started with. So then, could it do the
assignment _before_ the function call?
One would hope not. Why should the situation be any different
for...
i = (printf("%d\n", i), i) + 1;
...or...
i = (printf("%d\n", i++), i);
...or...
int f(int *i) { printf("%d\n", *i); return ++*i; }
i = f(&i);
Yes, an implementation can make deductions about the
expression, but the middle sequence point(s), and the
concept that the rhs must be evaluated, guarantees there
are no multiple assignments of the same object, and no
access for a purpose other than to compute the new
value, between sequence points for the cases above.
I don't know if C90 and C99 make this clear, but
without it, C would be defective IMO.
--
Peter
Beej Jorgensen
> Beej Jorgensen wrote:
>>
>> A B C D
>> | | | |
>> i = (i, i++, i) + 1
>>
>> i is modified twice between A and D, which causes UB by your above cite.
>> But what of sequence point C? Does it not count?
>>
> I think "previous and next" means the sequence point prior to the point of
> execution in the execution sequence, and next to the point of execution. In
> the UB scenario, the assignment happens between B and C.
Hmmm. Is that possible? I think it being possible hinges on us being
able to use the value of (i,i++,i) before the i++ side effect takes
place (since that value is needed for the assignment into i.)
C99 5.1.2.3p2:
# At certain specified points in the execution sequence called sequence
# points, all side effects of previous evaluations shall be complete and
# no side effects of subsequent evaluations shall have taken place.
So the assignment would have to count as a "previous evaluation" by
sequence point C...? That would imply that the entire + calculation
would also need to be complete by sequence point C...
C99 5.1.2.3p2 is all about "side effects"... it doesn't say anything
about the value computations. (in 201x the same paragraph clarifies
that it applies to both "every value computation and side effect".) Are
the value computations in C99 free to run off into the glorious future
and do all kinds of stuff beyond the sequence point before the sequence
point is hit? So, then, is this conforming pseudo-assembly that
demonstrates the UB in C99:
i = (i, i++, i) + 1
0 ;; == sequence point A ==
1 ;; == sequence point B ==
2 inc_i = i + 1
3 i = inc_i + 1 ; assignment
4 i = inc_i ; postincrement
5 ;; == sequence point C ==
6 ;; == sequence point D ==
Note that lines 3 and 4 can be interchanged, leading to the undefined
behavior.
(In 201x, I think this pseudo-assembly would be non-conforming because
the line 3 assignment would have to occur after sequence point C--thus
leading to a well-defined result.)
-Beej
Kaz Kylheku
> On 12/14/2009 02:36 PM, Johannes Schaub (litb) wrote:
>> Beej Jorgensen wrote:
>>>
>>> A B C D
>>> | | | |
>>> i = (i, i++, i) + 1
>>>
>>> i is modified twice between A and D, which causes UB by your above cite.
>>> But what of sequence point C? Does it not count?
>>>
>> I think "previous and next" means the sequence point prior to the point of
>> execution in the execution sequence, and next to the point of execution. In
>> the UB scenario, the assignment happens between B and C.
>
> Hmmm. Is that possible?
Not even by any halfway reasonable interpretation of C90.
Beej Jorgensen
I grant that, but what about my 25% reasonable interpretation? :-)
-Beej
Flash Gordon
<snip>
> Now, had the original example used "i" instead of "1" outside the parens:
>
> i = (i, i++, i) + i;
>
> then this would be a totally different question. I'm not certain if
> this constitutes "undefined" or "unspecified". However, given the same
> sequence points because of the comma operators, I would have to lean
> towards "unspecified".
I would say it is undefined, because there is no sequence point between
the i++ and the +i. It would still be undefined for the same reason if
you had
j = (i, i++, i) + i;
--
Flash Gordon
Richard
The simple fact is that the sequence is i, i++ and then i. It must be done
in that order. It would be ludicrous if the resultant was not the
initial value of i+1 IMO since the whole point of "sequence points"
would be lost.
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Kenneth Brody
You don't see any sequence point between "i++" and "+i" here?
i = (i, i++, i) + i;
^ ^
here and here
--
Kenneth Brody
Kenneth Brody
> Flash Gordon <sm...@spam.causeway.com> writes:
>
>> Kenneth Brody wrote:
>>
>> <snip>
>>
>>> Now, had the original example used "i" instead of "1" outside the parens:
>>>
>>> i = (i, i++, i) + i;
>>>
>>> then this would be a totally different question. I'm not certain if
>>> this constitutes "undefined" or "unspecified". However, given the same
>>> sequence points because of the comma operators, I would have to lean
>>> towards "unspecified".
>> I would say it is undefined, because there is no sequence point between
>> the i++ and the +i. It would still be undefined for the same reason if
>> you had
>> j = (i, i++, i) + i;
>
> The simple fact is that the sequence is i, i++ and then i. It must be done
> in that order. It would be ludicrous if the resultant was not the
> initial value of i+1 IMO since the whole point of "sequence points"
> would be lost.
But, the "+i" outside of the parens makes this, I believe, "unspecified".
There is no guarantee if the value of "i" will be taken before or after the
parenthesized expression.
However, I think that we're all in agreement that this qualifies as "don't
do that" type of code.
--
Kenneth Brody
Richard
> Richard wrote:
>> Flash Gordon <sm...@spam.causeway.com> writes:
>>
>>> Kenneth Brody wrote:
>>>
>>> <snip>
>>>
>>>> Now, had the original example used "i" instead of "1" outside the parens:
>>>>
>>>> i = (i, i++, i) + i;
>>>>
>>>> then this would be a totally different question. I'm not certain if
>>>> this constitutes "undefined" or "unspecified". However, given the same
>>>> sequence points because of the comma operators, I would have to lean
>>>> towards "unspecified".
>>> I would say it is undefined, because there is no sequence point between
>>> the i++ and the +i. It would still be undefined for the same reason if
>>> you had
>>> j = (i, i++, i) + i;
>>
>> The simple fact is that the sequence is i, i++ and then i. It must be done
>> in that order. It would be ludicrous if the resultant was not the
>> initial value of i+1 IMO since the whole point of "sequence points"
>> would be lost.
>
> But, the "+i" outside of the parens makes this, I believe,
> "unspecified".
Why? The left hand expression in brackets is a sequence of
expressions. The i++ MUST be evaluated before the last one or it makes
a mockery of the entire reason for sequence points IMO.
> There is no guarantee if the value of "i" will be taken before or after the
> parenthesized expression.
>
> However, I think that we're all in agreement that this qualifies as "don't
> do that" type of code.
--
Johannes Schaub (litb)
Those are not sequence points between "i++" and "+i". Those are sequence
points between "i", "i++" and "i". Notice that when we talk about "sequence
point between A and B" we are not talking about tokens, but about
evaluations - in the above case, evaluations of i++ and +i.
Johannes Schaub (litb)
You are missing that "i" is an "ihh" not a "one". So the previous value in
"i" is accessed *not* only to determine the new value to be stored, but
independently of the store action. This is what makes it undefined behavior.
Kaz Kylheku
>>>
>>> The simple fact is that the sequence is i, i++ and then i. It must be done
>>> in that order. It would be ludicrous if the resultant was not the
>>> initial value of i+1 IMO since the whole point of "sequence points"
>>> would be lost.
>>
>> But, the "+i" outside of the parens makes this, I believe,
>> "unspecified".
>
> Why? The left hand expression in brackets is a sequence of
> expressions. The i++ MUST be evaluated before the last one or it makes
> a mockery of the entire reason for sequence points IMO.
The + i makes it undefined. The operands of + can be evaluated in any
orer, nicluding interleaved and parallel. So this use violates the
second rule. The left operand of + makes modifications to i, which
race against the access of i on the opposite side. We don't know whether
this right hand side i is accessed before, during or after the i++
expression embedded in the left side.
Beej Jorgensen
>>>> Kenneth Brody wrote:
>>>>> i = (i, i++, i) + i;
| |
A B
> Why? The left hand expression in brackets is a sequence of
> expressions. The i++ MUST be evaluated before the last one or it makes
> a mockery of the entire reason for sequence points IMO.
But which subexpression will be evaluated first, A or B? C99 6.5p3 says
it's unspecified for operands of +.
-Beej
Johannes Schaub (litb)
> On 12/14/2009 02:36 PM, Johannes Schaub (litb) wrote:
>> Beej Jorgensen wrote:
>>>
>>> A B C D
>>> | | | |
>>> i = (i, i++, i) + 1
>>>
>>> i is modified twice between A and D, which causes UB by your above cite.
>>> But what of sequence point C? Does it not count?
>>>
>> I think "previous and next" means the sequence point prior to the point
>> of execution in the execution sequence, and next to the point of
>> execution. In the UB scenario, the assignment happens between B and C.
>
> Hmmm. Is that possible? I think it being possible hinges on us being
> able to use the value of (i,i++,i) before the i++ side effect takes
> place (since that value is needed for the assignment into i.)
>
> C99 5.1.2.3p2:
> # At certain specified points in the execution sequence called sequence
> # points, all side effects of previous evaluations shall be complete and
> # no side effects of subsequent evaluations shall have taken place.
>
> So the assignment would have to count as a "previous evaluation" by
> sequence point C...? That would imply that the entire + calculation
> would also need to be complete by sequence point C...
>
I honestly don't know. But it sounds strange, because even the simplest
things like "(i++, i++);" would not be possible, because each of the two
evaluations would have to be completed at the first sequence point, because
they are both side effects of the full expressions.
I think it all depends on what "previous evaluation" is. I have no clue -
but i thought it means an evaluation that started before the sequence point.
(but this would apply to any full expression, of course, so i see that can't
be right).
Another option is that "previous evaluation" means something stated by the
standard to be evaluated first. For instance, the comma operator sequences
both of its expressions by "The left operand of a comma operator is
evaluated as a void expression; there is a sequence point after its
evaluation. Then the right operand is evaluated;". Here, we can clearly see
the "before" and "after" relation with respect to the sequence point. The
sequence point would apply only to such cases - and would have no meaning to
other cases, like for evaluation of full expressions (except when done
transitively, of course).
In this scenario, of course, the assignment can be spread over all the left
side, and does not have to be complete before a sequence point. A problem
with this is that "changing the value of a scalar object twice between the
previous and next sequence point" is not not clear to me anymore then,
because: When is the value of the scalar object changed, if the change is
spread over multiple sequence points??
A third option is to see "side effect" as being one face of "evaluation"
(i.e: "the evaluation of a side effect of an expression"). This is even in
sync with Cx1, which defines "sequenced before" as being a relation on two
evaluations A and B, but then uses this relation to say something like "The
side effect A is sequenced before the side effect B". In this option, only
all previous side effects (i.e the one started already) need to be finished.
This would make examples like "(i++, i++)" valid again.
> C99 5.1.2.3p2 is all about "side effects"... it doesn't say anything
> about the value computations. (in 201x the same paragraph clarifies
> that it applies to both "every value computation and side effect".) Are
> the value computations in C99 free to run off into the glorious future
> and do all kinds of stuff beyond the sequence point before the sequence
> point is hit? So, then, is this conforming pseudo-assembly that
> demonstrates the UB in C99:
>
> i = (i, i++, i) + 1
>
> 0 ;; == sequence point A ==
> 1 ;; == sequence point B ==
> 2 inc_i = i + 1
> 3 i = inc_i + 1 ; assignment
> 4 i = inc_i ; postincrement
> 5 ;; == sequence point C ==
> 6 ;; == sequence point D ==
>
> Note that lines 3 and 4 can be interchanged, leading to the undefined
> behavior.
>
I believe this is a conforming translation as C99. The concepts about value
computations and how it relates to side effects isn't specified - only the
order of evaluation of expressions or the non-order, and the non-
interleaving of side effects (by sequence points). In this case, the
Standard has the assignment side effect and the increment unsequenced - even
if it might need a machine with "look-ahead" to get to such opportunities.
All very guesswork on my part, of course :/
Flash Gordon
Nope.
> i = (i, i++, i) + i;
> ^ ^
> here and here
I saw those sequence points, and can still see them, but they are not
between the i++ and the i. The reason being there is no sequencing
between the (i, i++, i) on one side of the + and the i on the other
side, so they could be interleaved. so if we number the i's as shown
below...
i = (i, i++, i) + i;
1 2 3 4 5
it could be evaluated in the order
i2 i3++ i5 i4
This gives no sequence point between i3++ and i5. I believe the draft of
C1x makes it clear that if any valid ordering leads to undefined
behavior then the behavior is undefined.
--
Flash Gordon
pete
I'm not evaluating the lone (i) which follows,
because I'm not evaluating the expression which contains it.
The meaning of the phrase "evaluate an expression" is at issue here.
If an expression has side effects,
then merely calculating its value,
is not an evaluation of the expression.
If you had to evaluate the right operand of every assignment operator
before making the assignment,
then assignment would be a sequence point, but it isn't.
--
pete
Kaz Kylheku
> Beej Jorgensen wrote:
>
>> o For the value computation of (i,i++,i) to be complete, i++'s side
>> effects must be complete.
>
> I disagree.
> I know that the value of (i,i++,i) is one greater
> than the original value of (i).
> I computed that without accomplishing any side effects.
You /must/ be trolling.
Computing the value of (i, i++, i) is /mathematically/ impossible without
modelling the side effect of i++, and reconciliation thereof by the comma
operator's sequence point.
Without the help of that sequence point, the final rightmost i does not
reliably refer to the incremented value.
You cannot reduce the expression to a stable value without taking into account
the sequence points and modeling them faithfully in your evaluation.
In your evaluation model, you must instantiate a representation of the object
i, and then perform the side effect upon it. There are no magic shortcuts.
Richard
> On 2009-12-14, pete <pfi...@mindspring.com> wrote:
>> Beej Jorgensen wrote:
>>
>>> o For the value computation of (i,i++,i) to be complete, i++'s side
>>> effects must be complete.
>>
>> I disagree.
>> I know that the value of (i,i++,i) is one greater
>> than the original value of (i).
>> I computed that without accomplishing any side effects.
>
> You /must/ be trolling.
>
> Computing the value of (i, i++, i) is /mathematically/ impossible without
> modelling the side effect of i++, and reconciliation thereof by the comma
> operator's sequence point.
>
Please explain this side affect keeping in mind there IS a sequence
point.
Kaz Kylheku
> Kenneth Brody wrote:
>> pete wrote:
>>
>>> Beej Jorgensen wrote:
>>>
>>>> o For the value computation of (i,i++,i) to be complete, i++'s side
>>>> effects must be complete.
>>>
>>>
>>> I disagree.
>>> I know that the value of (i,i++,i) is one greater
>>> than the original value of (i).
>>> I computed that without accomplishing any side effects.
>>
>>
>> But, in order for the result to be "one greater than the original value
>> of (i)", the side effect of incrementing "i" must have taken place
>> before evaluating the lone "i" which follows.
>>
>> You just disproved yourself. :-)
>>
>> QED.
>
> I'm not evaluating the lone (i) which follows,
> because I'm not evaluating the expression which contains it.
>
> The meaning of the phrase "evaluate an expression" is at issue here.
>
> If an expression has side effects,
> then merely calculating its value,
> is not an evaluation of the expression.
Who said that it was? Beej said above ``for the value computation
... to be complete, i++'s side effects must be complete''.
That is true, and value computation is not evaluation.
An expression can leave pending side effects, even though its value is already
known.
However an expression which contains a sequencing operator cannot
announce its value without having completed those side effects
which lie on the other side of that operator.
Given (A, B), we can know the value of the expression (derived from B) before
the expression is fully evaluated. Both A and B may have side effects. At the
time when we know the overall value of the expression, the side effects of A
are done and dusted. Those of B are not necessarily done.
> If you had to evaluate the right operand of every assignment operator
> before making the assignment,
Compeltely irrelevant, because in this debate, the issue is that
the right hand side contains a comma operator which provides the
sequencing.
Nobody is claiming that the assignment operator has a sequence point (which
would make expressions like i = i++ defined).
You're constructing something worse than a strawman; this is not a weakened
version of the position held by your debate opponents, but a completely
different position.
Your topic-shifting trolling tactic is 100% transparent at this point.
Kenneth Brody
> On 2009-12-15, Richard <rgr...@gmail.com> wrote:
>> Kenneth Brody <kenb...@spamcop.net> writes:
>>>>> j = (i, i++, i) + i;
>>>> The simple fact is that the sequence is i, i++ and then i. It must be done
>>>> in that order. It would be ludicrous if the resultant was not the
>>>> initial value of i+1 IMO since the whole point of "sequence points"
>>>> would be lost.
>>> But, the "+i" outside of the parens makes this, I believe,
>>> "unspecified".
>> Why? The left hand expression in brackets is a sequence of
>> expressions. The i++ MUST be evaluated before the last one or it makes
>> a mockery of the entire reason for sequence points IMO.
Yes, "i++" must be evaluated, and the side-effect completed, before
evaluating the "i" within the parenthesized expression. However, given
"a+b", there is no guarantee in which order "a" and "b" will be evaluated.
There is no guarantee that the "i" on the RHS of the "+" will be evaluated
before or after the parenthesized expression on the LHS of the "+".
> The + i makes it undefined. The operands of + can be evaluated in any
> orer, nicluding interleaved and parallel. So this use violates the
> second rule. The left operand of + makes modifications to i, which
> race against the access of i on the opposite side. We don't know whether
> this right hand side i is accessed before, during or after the i++
> expression embedded in the left side.
Noted. I was thinking the "i" must come either before or after the
"(i,i++,i)", hence "unspecified", but in parallel is also a possibility.
I hereby withdraw my "unspecified" and agree with "undefined".
--
Kenneth Brody
Richard
> Kaz Kylheku wrote:
>> On 2009-12-15, Richard <rgr...@gmail.com> wrote:
>>> Kenneth Brody <kenb...@spamcop.net> writes:
>>>>>> j = (i, i++, i) + i;
>>>>> The simple fact is that the sequence is i, i++ and then i. It must be done
>>>>> in that order. It would be ludicrous if the resultant was not the
>>>>> initial value of i+1 IMO since the whole point of "sequence points"
>>>>> would be lost.
>>>> But, the "+i" outside of the parens makes this, I believe,
>>>> "unspecified".
>>> Why? The left hand expression in brackets is a sequence of
>>> expressions. The i++ MUST be evaluated before the last one or it makes
>>> a mockery of the entire reason for sequence points IMO.
>
> Yes, "i++" must be evaluated, and the side-effect completed, before
> evaluating the "i" within the parenthesized expression. However, given
> "a+b", there is no guarantee in which order "a" and "b" will be evaluated.
> There is no guarantee that the "i" on the RHS of the "+" will be evaluated
> before or after the parenthesized expression on the LHS of the "+".
Oh I missed that. Fair point and time for me to engage brain. Watching
Tom break down into a shriek of name calling and credential posting I
must have drifter off to sleep.
>
>> The + i makes it undefined. The operands of + can be evaluated in any
>> orer, nicluding interleaved and parallel. So this use violates the
>> second rule. The left operand of + makes modifications to i, which
>> race against the access of i on the opposite side. We don't know whether
>> this right hand side i is accessed before, during or after the i++
>> expression embedded in the left side.
>
> Noted. I was thinking the "i" must come either before or after the
> "(i,i++,i)", hence "unspecified", but in parallel is also a possibility.
>
> I hereby withdraw my "unspecified" and agree with "undefined".
--
Johannes Schaub (litb)
In C99, it's totally irrelevant that there is a sequence point after "i++",
because the evaluation of the assignment expression ("i = (i, i++, i)") is
not after that sequence point, but it's *around* that sequence point: The
sequence point after "i++" is a part of the assignment expression (namely,
it appears in evaluation of its right side here).
As such, the Standard does not enforce that the assignment side effects does
not appear between the same pair of sequence points (and it doesn't even
agree the side effect is complete before any of the sequence points within
any of its operands). It only has to be complete at the full expression
sequence point. So, since we now have the value of the scalar changed
between the previous and the next sequence point more than one time
potentially (depending on how the implementation schedules the side
effects), we are running into UB.
spinoza1111
wrote:
> In article <87y6l7c5ek....@temporary-address.org.uk>,Nick <3-nos...@temporary-address.org.uk> wrote:
>
> ...
>
> >I often wonder why anyone cares about this sort of statement. It
> >doesn't look the sort of thing that might be produced by computer
> >generated code, and it doesn't look the thing you'd actually want to
> >write into a program. If it's that borderline and you'd never need it,
> >why does it actually matter, other than as a sort of C language sudoku.
>
> Indeed. Well put. ITA.
>
> But the point is that that is precisely the stock-in-trade of this
> newsgroup. As I have shown many times, it is not possible to post
> anything to this newsgroup, that will meet the generally accepted
> standards of "appropriateness", that is not either a) a topicality flame
> (gotta love them!) or b) language lawyering, of the type that is of no
> interest to the vast majority of working C programmers.
>
> Your post hits the nail on the head as to the sort of thing that people
> like Kiki, et al, just salivate over, but the rest of us find dull and
> uninteresting at best, and downright offensive at worst.
I think the problem is that too many posters are basically sitting
around companies in which actual programming is no longer performed,
and instead the "programmers" plan meetings to discuss the plan for
the next meeting to discuss the agenda for the end of year
meeting...you get the picture. Or they find what seem to be bugs and
then zip them over to Ulan Bator where the compiler experts, who are
genuinely intelligent and well trained, fix the problems.
In this environment, the topic *du jour* is a dull personal resentment
that dare not seek a constructive, if risky outlet. How much easier
and safer it must be to "laugh at" people with hearts and brains and
dicks, like Herb Schildt.
I mean, look at our "moderator" of comp.lang.c. Guy can't even be
troubled to email a poster who's made an error asking him wtf,
although THIS IS THE MODERATOR'S JOB. Instead, he allows an innocent
third party to get embarassed because he "volunteered" to moderate in
order to seem qualified, having not bothered to take a single computer
science class.
I conclude that American and developed countries have a sort of drone
class that constitute the recipients of an unnamed form of welfare.
That is, technology has in fact evolved to the point where, if we
factor out admittedly serious environmental impacts, only a few actual
workers are needed to keep things going. The rest need the services of
a welfare state but to explicitly offer these services creates
undecidable claims for larger shares of the pie.
Therefore, Job One in the corporation becomes covering up your
incompetence at what you were hired to do by loudly claiming that safe
targets are "incompetent" because, to quote dear Peter, "the 'heap' is
a DOS concept" (chortle).
Language lawyering, and berating people for not returning zero or what
ev er, becomes the train spotting, but it's bullshit, since in
actually advising real questioners, our little language lawyers forget
their lessons, as in a recent post where Kiki forgot to admonish a
questioner for not terminating a printf with a newline, or returning
zero, or declaring a void formal parameter.
It's welfare for white males.
spinoza1111
wrote:
> Kaz Kylheku wrote:
In discourse more sweet
(For Eloquence the Soul, Song charms the Sense)
Others apart sat on a hill retired,
In thoughts more elevate, and reasoned high
Of Providence, Foreknowledge, Will, and Fate--
Fixed fate, free will, foreknowledge absolute,
And found no end, in wandering mazes lost.
Of good and evil much they argued then,
Of happiness and final misery,
Passion and apathy, and glory and shame:
Vain wisdom all, and false philosophy!--
Yet, with a pleasing sorcery, could charm
Pain for a while or anguish, and excite
Fallacious hope, or arm th' obdured breast
With stubborn patience as with triple steel.
John Milton, Paradise Lost
Dennis (Icarus)
news:f11f4028-7391-4a10...@u8g2000prd.googlegroups.com...
<snip>
>
> I mean, look at our "moderator" of comp.lang.c. Guy can't even be
The newsgroup comp.lang.c does not have a moderator.
> troubled to email a poster who's made an error asking him wtf,
> although THIS IS THE MODERATOR'S JOB. Instead, he allows an innocent
> third party to get embarassed because he "volunteered" to moderate in
> order to seem qualified, having not bothered to take a single computer
> science class.
Surely you're aware that people can learn a subject, and quite well, without
having taken a class, right?
<snip>
Dennis
Richard Heathfield
<snip>
> The newsgroup comp.lang.c does not have a moderator.
It doesn't matter how many times this is said - there remain people
who will never understand or believe it.
<snip>
> Surely you're aware that people can learn a subject, and quite well,
> without having taken a class, right?
It is also my experience that some people can /teach/ a subject, and
quite badly, without ever having taken the trouble to learn that
subject. (I had such a teacher on my C course. For example, I had not
only to explain but actually to demonstrate to her that the
controlling condition on a loop is tested only once per iteration,
not after every single statement.) For this and other reasons, taking
a class is no guarantee of learning a subject properly. Nor is it a
guarantee of not learning the subject properly, however.
--
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
Kenny McCormack
Dennis \(Icarus\) <nojun...@ever.invalid> wrote:
>"spinoza1111" <spino...@yahoo.com> wrote in message
>news:f11f4028-7391-4a10...@u8g2000prd.googlegroups.com...
><snip>
>>
>> I mean, look at our "moderator" of comp.lang.c. Guy can't even be
>
>The newsgroup comp.lang.c does not have a moderator.
This sort of response is typical "reg BS".
The "scare quotes" that spinoza1111 used around the word should make it
clear (to anyone who wants to understand) that he knew that,
technically/officially, there is no moderator. He was clearly speaking
metaphorically. Equally clearly, several CLC regs have set themselves
up as being the moral equivalent of moderators.
Dennis (Icarus)
news:R7idnafOtfrCQ63W...@bt.com...
>> without having taken a class, right?
>
> It is also my experience that some people can /teach/ a subject, and
> quite badly, without ever having taken the trouble to learn that
> subject. (I had such a teacher on my C course. For example, I had not
> only to explain but actually to demonstrate to her that the
> controlling condition on a loop is tested only once per iteration,
> not after every single statement.) For this and other reasons, taking
> a class is no guarantee of learning a subject properly. Nor is it a
> guarantee of not learning the subject properly, however.
>
I guess the key thing for spinoza is that it appear on a transcript.
Whether you actually know the subject or had taken the class but forgot the
material due to the passing years, is irrelevant. :-)
Dennis
Dennis (Icarus)
"Kenny McCormack" <gaz...@shell.xmission.com> wrote in message
news:hgqmrt$msi$6...@news.xmission.com...
And yet, he also said
"troubled to email a poster who's made an error asking him wtf,
although THIS IS THE MODERATOR'S JOB."
It's in the part you snipped away.
If he truly thought there was no moderator, then there's no job to do. Since
he was faulting the person for not doing their job, it's looks like he
thought there was a moderator.
Pretty straightforward, for those who want to understand.
Dennis
Kenny McCormack
Dennis \(Icarus\) <nojun...@ever.invalid> wrote:
>Pretty straightforward, for those who want to understand.
>
>Dennis
>
Heh heh. You're funny.
I bet they called you "Dennis the Menace" when you were growing up.
Argonaut
But for anyone who follows comp.lang.c.moderated, it's clear that
Spinoza has confused this group with that, as he recently made a fool
out of himself there when he went for the throat of Peter Seibel.
This was unremarkable, for him, but eventually it became obvious that
he thought this was Peter Seebach. And when even he realised he'd
attacked an innocent person, he blamed the moderator of the group
(Seebach) for not stopping him (of course, if he had, Spinoza would
have been screaming about censorship) and reverted to attacking
Seebach.
Citing him in support of whatever your issues are with "CLC regs" is
not going to gain you any credibility.
Eric Sosman
> In<34a80$4b30dbca$cf62c293$54...@KNOLOGY.NET>, Dennis (Icarus) wrote:
>
> <snip>
>
>> The newsgroup comp.lang.c does not have a moderator.
>
> It doesn't matter how many times this is said - there remain people
> who will never understand or believe it.
What folly will you try to convince us of next? That
there is no cabal?
--
Eric Sosman
eso...@ieee-dot-org.invalid
Seebs
> If he truly thought there was no moderator, then there's no job to do. Since
> he was faulting the person for not doing their job, it's looks like he
> thought there was a moderator.
Spinoza's often crossposted things between clc and clcm, and of course,
there is a moderator of clcm. Who is, tragically, not omniscient, and
thus cannot always tell whether a particular incoherent rant will later be
alleged to have been an "error".
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
spinoza1111
wrote:
> In article <34a80$4b30dbca$cf62c293$5...@KNOLOGY.NET>,
>
> Dennis \(Icarus\) <nojunkm...@ever.invalid> wrote:
> >"spinoza1111" <spinoza1...@yahoo.com> wrote in message
> >news:f11f4028-7391-4a10...@u8g2000prd.googlegroups.com...
> ><snip>
>
> >> I mean, look at our "moderator" of comp.lang.c. Guy can't even be
>
> >The newsgroup comp.lang.c does not have a moderator.
>
> This sort of response is typical "reg BS".
> clear (to anyone who wants to understand) that he knew that,
> technically/officially, there is no moderator. He was clearly speaking
> metaphorically. Equally clearly, several CLC regs have set themselves
> up as being the moral equivalent of moderators.
This is the case. But I should have said the "moderator" of
comp.lang.c.moderated. Your point is well taken: in the unmoderated
group, some thugs pretend to be moderators.
spinoza1111
> On Tue, 22 Dec 2009 14:59:09 +0000 (UTC), gaze...@shell.xmission.com
>
>
>
>
>
> (Kenny McCormack) wrote:
> >In article <34a80$4b30dbca$cf62c293$5...@KNOLOGY.NET>,
> >Dennis \(Icarus\) <nojunkm...@ever.invalid> wrote:
> >>news:f11f4028-7391-4a10...@u8g2000prd.googlegroups.com...
> >><snip>
>
> >>> I mean, look at our "moderator" of comp.lang.c. Guy can't even be
>
> >>The newsgroup comp.lang.c does not have a moderator.
>
> >This sort of response is typical "reg BS".
> >clear (to anyone who wants to understand) that he knew that,
> >technically/officially, there is no moderator. He was clearly speaking
> >metaphorically. Equally clearly, several CLC regs have set themselves
> >up as being the moral equivalent of moderators.
>
> But for anyone who follows comp.lang.c.moderated, it's clear that
> Spinoza has confused this group with that, as he recently made a fool
> out of himself there when he went for the throat of Peter Seibel.
People whose business it is to create confusion have themselves to
pretend that they never make mistakes. But the way they do this is by
never being creative or helping others.
> This was unremarkable, for him, but eventually it became obvious that
> he thought this was Peter Seebach. And when even he realised he'd
> attacked an innocent person, he blamed the moderator of the group
> (Seebach) for not stopping him (of course, if he had, Spinoza would
> have been screaming about censorship) and reverted to attacking
> Seebach.
Well, the first thing I did was correct the record. Which is more than
I can say for the thugs here.
>
> Citing him in support of whatever your issues are with "CLC regs" is
> not going to gain you any credibility.
We don't want your credibility. You people lie to each other and to
newbies.
spinoza1111
> In <34a80$4b30dbca$cf62c293$5...@KNOLOGY.NET>, Dennis (Icarus) wrote:
>
> <snip>
>
> > The newsgroup comp.lang.c does not have a moderator.
>
> It doesn't matter how many times this is said - there remain people
> who will never understand or believe it.
>
> <snip>
>
> > Surely you're aware that people can learn a subject, and quite well,
> > without having taken a class, right?
>
> It is also my experience that some people can /teach/ a subject, and
> quite badly, without ever having taken the trouble to learn that
> subject. (I had such a teacher on my C course. For example, I had not
> only to explain but actually to demonstrate to her that the
> controlling condition on a loop is tested only once per iteration,
> not after every single statement.)
I find it hard to believe that she believed any such thing. Based on
my own experience with disruptive students with learning and
behavioral disorders, as well as your behavior here, I think you wrote
down something she said in class and thereafter interpreted it
literally, because you do so here and you are a Christian
Fundamentalist, where such folks set great store by literal
hermeneutics.
I think you then bullied her during the rest of the class,
monopolizing the class and creating confusion. I think you resented
her position and her gender. I think you unconsciously followed the
example of Nazi students.
> For this and other reasons, taking
> a class is no guarantee of learning a subject properly. Nor is it a
> guarantee of not learning the subject properly, however.
Nor is memorizing a standard, dear boy. Indeed, in the absence of even
flawed certification procedures, it becomes a matter of what loud fat
men say.
spinoza1111
wrote:
> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
Actually, I think that's only rarely true, although it is a favorite
myth of the sort of people you see actually attending wikipedia
conventions: fat, doughy, dull-eyed people who as cult members believe
that they can bypass traditional academia.
I think that autodidacts here consistently confuse the bad decisions
of C with computer science and in fact confuse a pre-science (a
grammatical taxonomy that is flawed) with actual science.
I also think that most of the autodidacts here have serious learning
and behavioral problems which have caused them to fail at university
studies, but to get hired by corporations that have long learned how
to use negative dynamics: to mobilize fear and low-level hatred to
make people "produce".
>
> <snip>
>
> Dennis
Kenny McCormack
spinoza1111 <spino...@yahoo.com> wrote:
...
(Some schmuck wrote)
>> It is also my experience that some people can /teach/ a subject, and
>> quite badly, without ever having taken the trouble to learn that
>> subject. (I had such a teacher on my C course. For example, I had not
>> only to explain but actually to demonstrate to her that the
>> controlling condition on a loop is tested only once per iteration,
>> not after every single statement.)
>
>I find it hard to believe that she believed any such thing. Based on
>my own experience with disruptive students with learning and
>behavioral disorders, as well as your behavior here, I think you wrote
>down something she said in class and thereafter interpreted it
>literally, because you do so here and you are a Christian
>Fundamentalist, where such folks set great store by literal
>hermeneutics.
You certainly got that right. Given that the whole game in CLC (and,
unfortunately, in Usenet as a whole, but nowhere else [IME] as severe
and unforgiving as in CLC) is to stare at something, that someone else
wrote, until you can come up with an absurd interpretation. Then you
post a reply that assumes that that interpretation is the only possible
one.
Richard
And like Heathfield's fantasy land stories about how he reformatted a
hard drive because of UB back in 89, most stories are conjured up to
provide a reason for their anal retentiveness and lack of real life
awareness. But this years prize for most exagerrated tall tales that
refer to dinosaur machines must go to Flash Gordon. It seems he never
programmed a machine what was not missing a bit, alternate endian or had
no stack.
spinoza1111
wrote:
We can change this, Kenny. The new game starts now. And the rules are
found in The Psychology of Computer Programming: no personal attacks,
just problem solving, active tolerance of alternate points of view,
and the absolute right of personal verbal self-defense.
spinoza1111
> gaze...@shell.xmission.com (Kenny McCormack) writes:
> > In article <2a355def-4f02-4222-8d35-5680ac537...@j9g2000prh.googlegroups.com>,
My current favorite is Heathfield's claim that his teacher said that
for loop exit is tested before each statement in the for loop. It is
not impossible, depending on what low level technical Borstals he may
have been sent to as a ward of the state (that's irony not a claim)
but it's likelier that he deliberately misinterpreted her when she
said (correctly), "children, the statement after the for loop is
executed while the for loop condition is true". She was correct
because that is the syntax of the for loop:
forLoop := "for" "(" [ initialization ] ";" condition
";" [ modification ] ")"
statement
since "statement" can be a simple or compound "statement".
Richard may have misheard her and jumped all over the poor lady.
Richard
Argonaut
<spino...@yahoo.com> wrote:
>We can change this, Kenny. The new game starts now. And the rules are
>found in The Psychology of Computer Programming: no personal attacks,
>just problem solving, active tolerance of alternate points of view,
>and the absolute right of personal verbal self-defense.
Great! The all-new, touchy, feely, sensitive Spinoza!
Which lasted 6 minutes, till you attacked Heathfield:
On Wed, 23 Dec 2009 05:42:56 -0800 (PST), spinoza1111
<spino...@yahoo.com> wrote:
>My current favorite is Heathfield's claim that his teacher said that
>for loop exit is tested before each statement in the for loop. It is
>not impossible, depending on what low level technical Borstals he may
>have been sent to as a ward of the state (that's irony not a claim)
>but it's likelier that he deliberately misinterpreted her when she
Where you presume you know facts of his childhood better than he does.
In which case you're a seriously obsessed stalker, or psychic.
Meanwhile,
On Thu, 10 Dec 2009 12:16:21 -0600 (CST), spinoza1111
<spino...@yahoo.com> wrote:
> Therefore, to save SEEBACH work, and to avoid further
>confusion as a result of a flame war I will not post anything further
>at this thread.
-- followed up in that thread by at least four of your trademark
apoplectic tirades.
And on that topic, I note that while you over and over accuse Seebach
of leading some kind of vendetta against Schildt, searching the
newsgroup that he set up and controls, as moderator,
(comp.lang.c.moderated, where you recently shat in your own pants)
shows that until you turned up , Schildt had not been mentioned once
in the last seven years. Now that's a real sneaky way to run a
vendetta. What an evil mastermind.
Richard
> On Wed, 23 Dec 2009 05:36:28 -0800 (PST), spinoza1111
> <spino...@yahoo.com> wrote:
>
>>We can change this, Kenny. The new game starts now. And the rules are
>>found in The Psychology of Computer Programming: no personal attacks,
>>just problem solving, active tolerance of alternate points of view,
>>and the absolute right of personal verbal self-defense.
>
> Great! The all-new, touchy, feely, sensitive Spinoza!
>
> Which lasted 6 minutes, till you attacked Heathfield:
>
> On Wed, 23 Dec 2009 05:42:56 -0800 (PST), spinoza1111
> <spino...@yahoo.com> wrote:
>>My current favorite is Heathfield's claim that his teacher said that
>>for loop exit is tested before each statement in the for loop. It is
>>not impossible, depending on what low level technical Borstals he may
>>have been sent to as a ward of the state (that's irony not a claim)
>>but it's likelier that he deliberately misinterpreted her when she
>
> Where you presume you know facts of his childhood better than he does.
> In which case you're a seriously obsessed stalker, or psychic.
So you believe that Heathfield's C teacher thought the condition was
tested for each and ever inner statement? No you don't.
>
> Meanwhile,
> On Thu, 10 Dec 2009 12:16:21 -0600 (CST), spinoza1111
> <spino...@yahoo.com> wrote:
>> Therefore, to save SEEBACH work, and to avoid further
>>confusion as a result of a flame war I will not post anything further
>>at this thread.
>
> -- followed up in that thread by at least four of your trademark
> apoplectic tirades.
>
> And on that topic, I note that while you over and over accuse Seebach
> of leading some kind of vendetta against Schildt, searching the
> newsgroup that he set up and controls, as moderator,
> (comp.lang.c.moderated, where you recently shat in your own pants)
> shows that until you turned up , Schildt had not been mentioned once
> in the last seven years. Now that's a real sneaky way to run a
> vendetta. What an evil mastermind.
>
Nothing was mentioned there which is why he come slinking into here.
Seebs
> And on that topic, I note that while you over and over accuse Seebach
> of leading some kind of vendetta against Schildt, searching the
> newsgroup that he set up and controls, as moderator,
> (comp.lang.c.moderated, where you recently shat in your own pants)
> shows that until you turned up , Schildt had not been mentioned once
> in the last seven years. Now that's a real sneaky way to run a
> vendetta. What an evil mastermind.
The secret to my vendetta is delegation. Having no interest in actually
pursuing the vendetta (indeed, having been totally unaware of it), I
apparently subcontracted it to a Usenet kook who would go around preaching
to everyone and anyone that would listen that Schildt's work was, according
to me, garbage, and according to the kook, the ideal salvation of the human
race. This has, I suspect, done more to undermine Schildt's reputation
than my web page ever did.
Richard Heathfield
> On Wed, 23 Dec 2009 05:36:28 -0800 (PST), spinoza1111
> <spino...@yahoo.com> wrote:
>
>>We can change this, Kenny. The new game starts now. And the rules
>>are found in The Psychology of Computer Programming: no personal
>>attacks, just problem solving, active tolerance of alternate points
>>of view, and the absolute right of personal verbal self-defense.
>
> Great! The all-new, touchy, feely, sensitive Spinoza!
>
> Which lasted 6 minutes, till you attacked Heathfield:
If you were expecting rationality and consistency from him, I suggest
a reappraisal.
> On Wed, 23 Dec 2009 05:42:56 -0800 (PST), spinoza1111
> <spino...@yahoo.com> wrote:
>>My current favorite is Heathfield's claim that his teacher said that
>>for loop exit is tested before each statement in the for loop. It is
>>not impossible, depending on what low level technical Borstals he
>>may have been sent to as a ward of the state (that's irony not a
>>claim) but it's likelier that he deliberately misinterpreted her
>>when she
>
> Where you presume you know facts of his childhood better than he
> does. In which case you're a seriously obsessed stalker, or psychic.
For the record, I was 26 years old at the time. There was no
misinterpretation, deliberate or otherwise. I asked her to clarify
what she meant, and wrote some code that would give different results
depending on whether the loop condition was, or was not, tested after
every statement, leaving us both in no doubt about what she meant.
And what she meant was wrong. I demonstrated this to her, and she at
least had the good grace to recognise that she was wrong, and to make
her mistake clear to the class at the next opportunity.
The hysterically incredulous barking of ignorant Usenet idiots does
not change the facts of the matter in the slightest.
> Meanwhile,
> On Thu, 10 Dec 2009 12:16:21 -0600 (CST), spinoza1111
> <spino...@yahoo.com> wrote:
>> Therefore, to save SEEBACH work, and to avoid further
>>confusion as a result of a flame war I will not post anything
>>further at this thread.
>
> -- followed up in that thread by at least four of your trademark
> apoplectic tirades.
Yeah, you know he's a hypocritical idiot and I know he's a
hypocritical idiot, but we both know he's going to keep on posting
gibberish no matter what we say.
<snip>
Eric Sosman
> On Wed, 23 Dec 2009 05:36:28 -0800 (PST), spinoza1111
> <spino...@yahoo.com> wrote:
>
>> We can change this, Kenny. The new game starts now. And the rules are
>> found in The Psychology of Computer Programming: no personal attacks,
>> just problem solving, active tolerance of alternate points of view,
>> and the absolute right of personal verbal self-defense.
>
> Great! The all-new, touchy, feely, sensitive Spinoza!
Just two requests: First, please stop feeding the troll.
Second, if you cannot resist the urge to feed him, please
refer to him as "Nilges" and not by the revered names like
Spinoza and Orwell that he has misappropriated for his own
scummy purposes.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Seebs
> Just two requests: First, please stop feeding the troll.
> Second, if you cannot resist the urge to feed him, please
> refer to him as "Nilges" and not by the revered names like
> Spinoza and Orwell that he has misappropriated for his own
> scummy purposes.
I like "Spinny". Spinoza, he ain't. A sort of cheap knock-off of Spinoza,
I could buy.
Also, he gets really offended when you besmirch his family name, as a result
of which, I feel that associating it with his behavior is probably pretty
offensive to him.
spinoza1111
Even if this is true, it means that you took classes in programming
from laughably unqualified people. That alone could be remediated but
we also have your poor performance on the Sparknotes test to show that
you are not an "expert" on the topics you profess.
However, I believe you deliberately disrupted the class as you disrupt
conversations here by deliberately taking one mis-statement by a
female teacher. I believe your fear of women played a role. I believe
she humored you as I humored "Otto" in my classes.
She probably meant that the loop condition is true during the
execution of each statement in the block in the loop scope and that
you COULD repeat the test before each statement since each statement
lies before the modification, UNLESS a statement in the block changed
the loop condition. She may have been making a subtle point that
escaped you: that it's poor practice to allow the condition to become
false in the loop body. She may have been talking about program
verification and it was over your head, therefore you jumped on her as
you jump on people here.
The code you wrote was probably pathological whereas she wanted you to
code loops that did not modify the loop condition.
spinoza1111
> On 2009-12-23, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>
> > Just two requests: First, please stop feeding the troll.
> > Second, if you cannot resist the urge to feed him, please
> > refer to him as "Nilges" and not by the revered names like
> > Spinoza and Orwell that he has misappropriated for his own
> > scummy purposes.
>
> I like "Spinny". Spinoza, he ain't. A sort of cheap knock-off of Spinoza,
> I could buy.
>
> Also, he gets really offended when you besmirch his family name, as a result
> of which, I feel that associating it with his behavior is probably pretty
> offensive to him.
Decent people usually get offended when you besmirch their family
name. You might not care about bringing shame on your father or
Schildt's family, but I think it is wrong.
I've used spinoza1111 since 1996 because Baruch Spinoza was "flamed"
by the Amsterdam Jewish community for his views.
The issue is not my behavior, it is yours. Since you're an Apress
author, I advise you as an older one to withdraw the Schildt canard
since it brings disrepute on Apress as a whole and indirectly may harm
my sales.
>
> -s
> --
> Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
spinoza1111
> On Wed, 23 Dec 2009 05:36:28 -0800 (PST),spinoza1111
>
> >We can change this, Kenny. The new game starts now. And the rules are
> >found in The Psychology of Computer Programming: no personal attacks,
> >just problem solving, active tolerance of alternate points of view,
> >and the absolute right of personal verbal self-defense.
>
> Great! The all-new, touchy, feely, sensitive Spinoza!
Reread the part about self-defense. Heathfield disrupts conversations
and enables campaigns of personal destruction. We have the right of
collective and individual self-defense against his attacks. But we do
NOT initiate them by deliberately misinterpreting what people say into
charges of incompetence.
The "soft male" is raised by women to not defend himself but
compensates by bullying safe targets.
stan
> On Dec 24, 12:47�am, Argonaut <A...@naut.com> wrote:
>> On Wed, 23 Dec 2009 05:36:28 -0800 (PST),spinoza1111
>>
>> <spinoza1...@yahoo.com> wrote:
>> >We can change this, Kenny. The new game starts now. And the rules are
>> >found in The Psychology of Computer Programming: no personal attacks,
>> >just problem solving, active tolerance of alternate points of view,
>> >and the absolute right of personal verbal self-defense.
>>
>> Great! The all-new, touchy, feely, sensitive Spinoza!
>
> Reread the part about self-defense. Heathfield disrupts conversations
> and enables campaigns of personal destruction. We have the right of
> collective and individual self-defense against his attacks. But we do
> NOT initiate them by deliberately misinterpreting what people say into
> charges of incompetence.
"We" - the plot thickens!
Seebs
> "We" - the plot thickens!
Don't read too much into it, I think he just can't count.
-s
--
spinoza1111
> On 2009-12-24, stan <smo...@exis.net> wrote:
>
> > "We" - the plot thickens!
>
> Don't read too much into it, I think he just can't count.
In a bullying situation, it is important to re-present the victim as
isolated and friendless, which is actually the secret contour of the
bully's weakness. The fact is that your treatment of Schildt has been
criticized by others, and Schildt thanked me for my change to the
wikipedia article last year. In addition, the spamming of Amazon by
people whose sole source is your essay has been criticized by third
parties at Amazon.
Instead of fairly and humanely discussing programming issues (with its
attendant risks in this first-draft and unedited environment of making
errors), people prefer
(1) Negative, smirking claims ("undefined") which in their generality
are safer because more likely to be true, but which don't educate: we
need to know what compilers evaluate undefined C expressions in which
way in maintaining pathological software but no information is
provided
(2) Focusing on personalities instead of ideas. It's safer to trash
personalities since discussing ideas may anger employers
>
> -s
> --
Argonaut
<spino...@yahoo.com> wrote:
>On Dec 24, 12:47�am, Argonaut <A...@naut.com> wrote:
>> On Wed, 23 Dec 2009 05:36:28 -0800 (PST),spinoza1111
>>
>> <spinoza1...@yahoo.com> wrote:
>> >We can change this, Kenny. The new game starts now. And the rules are
>> >found in The Psychology of Computer Programming: no personal attacks,
>> >just problem solving, active tolerance of alternate points of view,
>> >and the absolute right of personal verbal self-defense.
>>
>> Great! The all-new, touchy, feely, sensitive Spinoza!
>
>Reread the part about self-defense. Heathfield disrupts conversations
>and enables campaigns of personal destruction. We have the right of
>collective and individual self-defense against his attacks. But we do
>NOT initiate them by deliberately misinterpreting what people say into
>charges of incompetence.
"SELF" defense does not give you the license to call Heathfield a Nazi
youth in response to an anecdote he told about his teacher, which had
nothing at all to do with you, and of which you have no knowledge at
all to base your accusations.
Of course, you've added some weasel words extending "self defense" to
"collective" which you imagine gives you the right to act on anyone
else's behalf. So you've appointed yourself a free-agent vigilante.
Actually, it seems very likely that the origin of your Quixotic
"Defend Schildt" campaign was some remark your nemesis Heathfield made
about him, and you appointed yourself Schildt's defender simply to
give yourself a stick to beat him with, while claiming you were acting
to defend Schildt's (and even his family's) reputation.
And do you have a macro to type "campaigns of personal destruction"?
It would save you a lot of time.
spinoza1111
> On Wed, 23 Dec 2009 19:14:22 -0800 (PST),spinoza1111
>
>
>
>
>
> <spinoza1...@yahoo.com> wrote:
> >On Dec 24, 12:47 am, Argonaut <A...@naut.com> wrote:
> >> On Wed, 23 Dec 2009 05:36:28 -0800 (PST),spinoza1111
>
> >> <spinoza1...@yahoo.com> wrote:
> >> >We can change this, Kenny. The new game starts now. And the rules are
> >> >found in The Psychology of Computer Programming: no personal attacks,
> >> >just problem solving, active tolerance of alternate points of view,
> >> >and the absolute right of personal verbal self-defense.
>
> >> Great! The all-new, touchy, feely, sensitive Spinoza!
>
> >Reread the part about self-defense. Heathfield disrupts conversations
> >and enables campaigns of personal destruction. We have the right of
> >collective and individual self-defense against his attacks. But we do
> >NOT initiate them by deliberately misinterpreting what people say into
> >charges of incompetence.
>
> "SELF" defense does not give you the license to call Heathfield a Nazi
> youth in response to an anecdote he told about his teacher, which had
> nothing at all to do with you, and of which you have no knowledge at
> all to base your accusations.
Nothing has anything to do with anything if an addictive system has no
memory. However, Heathfield's conduct does resemble, as far as I can
tell from (1) my experience here, (2) my experience in SDS in the
1960s, and (3) my reading that of radical left students in the 1960s
and that of Nazi youth in the 1930s.
>
> Of course, you've added some weasel words extending "self defense" to
> "collective" which you imagine gives you the right to act on anyone
> else's behalf. So you've appointed yourself a free-agent vigilante.
Nope, I just decided to investigate the matter of Schildt, because
when I submitted intelligent and well received comments on programming
professionalism to comp.programming in 2000, about the time I was
invited by Princeton University Press to an online panel on Internet
issues alongside Mike Godwin, I found myself targeted by Richard
Heathfield in a Topic Vendetta in which he said "comp.programming is
not about programmers".
I also noted that Heathfield, the unsuccessful editor of a poorly-
received computer book, had a hair up his ass about the much more
successful Herb Schildt, whose "Born to Code" book I'd read and liked
in 1989, and I decided to investigate the matter. I reasoned that one
way to stop what seemed to be bullying was not only self-defense,
because that would be interpreted as bias. I also had seen bullying
teachers in my high school in the 1960s confronted by my fellow
students, who defended my right to wear black armbands to protest
Vietnam even though many of them hated my guts. I'd seen that
solidarity overcomes bullying, because bullying is how illegitimate
power legitimises itself.
I wasn't particularly impressed by Schildt's work after Born to Code
based on my own experience in assisting Nash, and I did feel he needed
to use a wider range of compilers and platforms. However, I also
realized that by 2000, C had become a mess and that to be truly
encyclopedic about C was nearly impossible. It's not a well-definable
programming language as shown by "sequence points" which are an ugly
hack not found in discussions of better languages.
>
> Actually, it seems very likely that the origin of your Quixotic
> "Defend Schildt" campaign was some remark your nemesis Heathfield made
> about him, and you appointed yourself Schildt's defender simply to
> give yourself a stick to beat him with, while claiming you were acting
> to defend Schildt's (and even his family's) reputation.
Overall, that is correct. Yes, Heathfield pisses me off. But this is
because he's disruptive and a trouble maker who consistently
interrupts technical discussions by labeling, or enabling the
labeling, of one of the discussants as incompetent. He's one of those
programmers who's justly terrified that his own inadequacy will be
exposed and seeks to label others for this reason. If I only defended
myself, then I'd be biased. But on investigation I discovered that
Heathfield was also attacking a well-received (in the sense of sales)
computer book, and as a published author, I knew that a language
standard is a different *genre* from a computer book, since the
mission of the latter is to teach. To teach means to use examples that
the student must use as a basis for generalization, as in the case of
the high school geometry teacher who uses one triangle to show
something true for all triangles.
>
> And do you have a macro to type "campaigns of personal destruction"?
> It would save you a lot of time.
I prefer to think about what I write. If I have to repeat myself, so
be it. I am saying that this newsgroup could be useful if people came
here less ready to INITIATE such campaigns, and more ready to DEFEND
themselves like men.
Ike Naar
spinoza1111 <spino...@yahoo.com> wrote:
>She probably meant that the loop condition is true during the
>execution of each statement in the block in the loop scope and that
>you COULD repeat the test before each statement since each statement
>lies before the modification, UNLESS a statement in the block changed
>the loop condition. She may have been making a subtle point that
>escaped you: that it's poor practice to allow the condition to become
>false in the loop body. She may have been talking about program
>verification and it was over your head, therefore you jumped on her as
>you jump on people here.
Are you confusing "loop condition" with "loop invariant"?
It is good practice to maintain the truth of the loop invariant,
but the loop condition *must* be falsified at some point, otherwise
the loop does not terminate.
You design a loop in such a way that the desired result (the condition
that you want to be true after the loop finishes) follows from
the conjunction of the loop invariant and the negation of the loop
condition.
So, your loop goes like:
establish loop_invariant;
while (loop_condition)
{
work toward falsification of loop_condition, preserving loop_invariant;
}
"loop_invariant and not loop_condition" holds;
For the sake of efficiency, you want loop_condition to become false
as soon as possible.
spinoza1111
> In article <752a827c-0c93-4893-b548-6957fed21...@a10g2000pre.googlegroups.com>,
>
> spinoza1111 <spinoza1...@yahoo.com> wrote:
> >She probably meant that the loop condition is true during the
> >execution of each statement in the block in the loop scope and that
> >you COULD repeat the test before each statement since each statement
> >lies before the modification, UNLESS a statement in the block changed
> >the loop condition. She may have been making a subtle point that
> >escaped you: that it's poor practice to allow the condition to become
> >false in the loop body. She may have been talking about program
> >verification and it was over your head, therefore you jumped on her as
> >you jump on people here.
>
> Are you confusing "loop condition" with "loop invariant"?
No.
> It is good practice to maintain the truth of the loop invariant,
> but the loop condition *must* be falsified at some point, otherwise
> the loop does not terminate.
Yes. But to verify the program's correction you need both.
>
> You design a loop in such a way that the desired result (the condition
> that you want to be true after the loop finishes) follows from
> the conjunction of the loop invariant and the negation of the loop
> condition.
Correctomundo.
>
> So, your loop goes like:
>
> establish loop_invariant;
> while (loop_condition)
> {
> work toward falsification of loop_condition, preserving loop_invariant;
> }
> "loop_invariant and not loop_condition" holds;
>
> For the sake of efficiency, you want loop_condition to become false
> as soon as possible.
Right, but you don't, as Heathfield's probably mythical She Devil C
Teacher From Hell claimed in his probably fabricated, bother in most
imaginable cases to test the condition after each statement. In a zero
trip loop you test it at the start, in a one tripper at the end, and
in a "breaking" loop somewhere in the middle.
[Hey Richard! Was she hot?]
I suppose that in some deep optimization, where ANY of the conditions
may falsify the loop condition, you might test the loop condition
after each statement if it's easy to do so.
Richard's up to his usual shit: making false claims and spreading
confusion as opposed to Sweetness and Light.