sequence points in subexpressions

[Seebs]

Also "Argonaut," it seems. <PLONK>

No, he tried the experiment, concluded that the results were negative,
and stopped. Within the last day or so.

-s

 

[spinoza1111]

If the Mohawk fits, and it does, wear it.
(Wrong year, by the way.)


Your endless gushing of absurd insults is not "hard to parse" as you

Insults? Try valid arguments, which are insulting only if you're not
qualified to respond.

Richard Heathfield has repeatedly lied about people. I respond,
showing how he does so by demonstrating, for example, that it's easy
to find 37 Nilges hits in the comp.risks archive.

But, automatic analysis of my text would I'm sure show a longer
average length, a wider vocabulary, fewer errors of grammar or
orthography, and a greater depth of nesting of complex clauses.

Most people run out of steam in at least two ways. Most people
(English professors have long observed) are incapable of constructing
a complex sentence whose parse tree order > 2. When confronted with
the negation of their assertions, most people here negate the
negation, and, lacking anything else to say, change the subject to the
global incompetence and evil intentions of their correspondent.

I get flamed mostly because like Joe Normal in Mike Judge's movie
Idiocracy, who wakes up in 2500 AD, I seem to you to talk like a fag
and a 'tard, and my shit seems fucked up. I have a measured IQ of only
120, but was trained, and educated myself, in writing above today's
low level of complexity in Catholic schools of the 1950s. We had to
memorize poetry and the Tridentine Mass: we had to draw sentence
diagrams: and, for papers, we didn't make mindless "mind maps": we
made proper outlines conforming to strict rules.

Whereas most of you have been mollycoddled as little white boys in
schools where you were never required to read or write above a basic
level, and many of you switched to the programming field to escape
your humiliation in English class, there to bully teachers by
deliberately misinterpreting what they said. By that time, many of you
had been forced by grim economic necessity to start work in a variety
of cheesy banks and insurance firms as programmers and this seemed,
albeit constructed, the "real world" against which you measured your
professors and found them wanting.

This, I think, explains the rage here.

 

[spinoza1111]

spinoza1111wrote:

Did you cut and paste this from somewhere?

Uh...no. I can respond in extempore verse of you like!

Kenny, this we can change
Oh Kenny, and this we can alter
Replace this game, this dog and its mange
With a new game, oh do not falter.
Let the new game begin,
And what are the rules?
They are not found in the writings of fools
They're found in...the Psychology of Computer Programmin'.
No personal attacks,
Especially not for talking of stacks:
Focus on the problem *undt seinem* solution.
And beautiful Tolerance, an angel from heaven
Shall discussions here henceforth leaven.
She shall smile on colliding points of view,
Interpersonal horseshit shall make her to rue:
But above all, are we not men
Therefore I say and say it again
None can give any offence
If he exercises his right of self-defence.

Pretty good for one pass and no revision, right? One minute flat.
Betcha didn't know I was a poet, probably thought I was just a jag.

Betcha didn't know I was a poet
That I was a poet ya didn't know it
Instead ya probably thought and odds are it's been your bag
That I'm a most egregious and unfortunate Jag.

In contrast to the above, this sure seems like an unprovoked personal
attack with absolutely no attempt to solve any problem; particularly
any on topic C problem.

But it's not "unprovoked", is it, if, in fact, Richard Heathfield
frequently enters discussions, chooses one side or the other, and
makes comments about the other side not to him, but to his
correspondents, in which those comments generalize globally in a
speculative fashion about the selected target's competence.

Gerald Weinberg's insight was that in conversations where one or more
people feel threatened, those people will cease contributing to, and
actively impede, the group problem-solving effort, and this is why
actual solutions or working code so seldom emerges from clc or clcm.

How would you describe your behavior?

As the exercise of verbal self-defense. Without this right, it's the
law of the jungle.

This particular rant is an unprovoked attack which uses non-free
bandwidth. Why not go green and give us a break for the new year?

But, as I have shown, it is not unprovoked.

So in 2000 you submitted a rebuttal; now years down the road it's
simply venomous, irrational screetching.

No, in all cases Richard Heathfield has kept the process going. In
fact, I've taken a large number of sabbaticals and called upon
Heathfield to do so as well, which he has not.

We really do get it, you don't really need to say it every 15 minutes.


Actually he neither disrupted nor hijacked this thread; that was you.

It appears he has indeed taken a semi-sabbatical in that he's probably
engaged in wass-hail, the singing of seasonal anthems off-key for
Christmas cake or recovering from excessive heartiness of the season.
Which is good, and unprecedented.

I suppose if you think the best defense is a good offense your
behavior could constitute some kind of attempted defense. If you want
to appear at least slightly rational, try quoting the attack you feel
threatened you. Your fear is really hard to understand, and your
response seems unproportional in any event.

Just a thought; why not write a C program that generates hateful
responses and accuses people. Then you could simply post the program
instead of endless rants and at least you would have mentioned
something relevant to this newsgroup. You could then polish it over
time and demonstrate you self-proclaimed considerable skill and we
could learn something about C programming.

Been done.

 

[Dennis \(Icarus\)]

I am, thank you.

I still think that the real Edward Nilges will be pissed when he sees the
damage being done to his reputation and credibility by spinoza1111.

Dennis

 

[Kenny McCormack]

I still think that the real Edward Nilges will be pissed when he sees the
damage being done to his reputation and credibility by spinoza1111.

And I'm sure you believe in the Tooth Fairy and the Easter Bunny as well.

 

[Seebs]

I still think that the real Edward Nilges will be pissed when he sees the
damage being done to his reputation and credibility by spinoza1111.

Huh.

That'd be a treat; what if it were the ACTUAL Edward Nilges trying to
contact me variously out of band, and I've been mistakenly ignoring him,
thinking he was spinoza1111?

-s

 

[spinoza1111]

I still think that the real Edward Nilges will be pissed when he sees the
damage being done to his reputation and credibility byspinoza1111.

Dennis

(Cue Twilight Zone)

Buy my book (or I'll kill this dog). I provide an email address,
(e-mail address removed), in that book.

This is absurd! You're unable to actually deal with vigorous views
which in fact closely resemble some of the OUTRAGEOUS claims I make in
"Build Your Own .Net Language and Compiler", such as "Nixon invaded
Cambodia while I was learning computer science" (true!) and that "you
can write a compiler in Visual Basic!" (true!).

Literate and cultivated adults are able to read outrageous books such
as Tolstoy's outrageous Anna Karenina, with its outrageous ending in
which a bourgeois woman leaps in front of a train. Technicians are
shocked and stop reading.

 

[spinoza1111]

[...]
And as Keith Thompson may be happy to hear, I'm thus signing off from
any further attempt to stem your toxic flow.
I am, thank you.

I still think that the real Edward Nilges will be pissed when he sees the
damage being done to his reputation and credibility byspinoza1111.

And I'm sure you believe in the Tooth Fairy and the Easter Bunny as well.

I think the Tooth Fairy is HOT, and should visit older men who are
losing their mature teeth, and give them a blow job instead of leaving
money.

 

[spinoza1111]

Huh.

That'd be a treat; what if it were the ACTUAL Edward Nilges trying to
contact me variously out of band, and I've been mistakenly ignoring him,
thinking he wasspinoza1111?

Well, it was, dear boy. Edward G. Nilges, your fellow starving author
at Apress, tried to contact you to discuss his (my) concerns about
your behavior, and you didn't even read the email. Next time, think
twice before alienating people who might be coworkers or colleagues.
What if Schildt becomes your boss?

[Love to be a fly on the wall in the status meeting where THAT was
announced. Petey goes green, then white, and starts to make little
moaning noises...]

 

[Tim Rentsch]

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.

No, defined behavior. Larry Jones has explained in a c.l.c posting
that the new language to support multi-threading doesn't change the
single thread semantics.

 

[Tim Rentsch]

It does.


That's wrong.


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,

Ask yourself what happens in the abstract machine. In the
abstract machine, the expression

(i, i++, i)

must be evaluated to get the value of 'i' (the last 'i'),
so that the assignment may be performed. To get the
value of the last 'i', the 'i++' must have been already
evaluated and all side effects completed, because evaluating
the comma operator gives a sequence point after the left
operand, and it is the comma operator that yields the value
of the final 'i'.

In the abstract machine, operands are always evaluated before the
operations they are operands for, and evaluating a comma operator
means any side effects of the left hand side are complete before
evaluating the right hand side, and so also before the comma
operation of yielding the right hand side value. So by the
time we get to starting the assignment operation, any side
effects due to 'i++' have completed.

 

[Tim Rentsch]

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?

Presumably you mean
*(p += i, ++i, p += i) = (j++, ++j, j);

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;

Yes (ignoring possible overflows).

What do we know about *which* sequence points are
reached first, right-side vs left-side, or can they
be interelaved?

Look at the abstract syntax tree for a single expression. The
end-of-full-expression puts a sequence point after all the
subexpressions in the tree (and the last end-of-full-expression
puts a sequence point before all the subexpressions in the tree).
A sequencing operator (such as comma, ||, &&, ? put a sequence
point _after_ all subexpressions of the leftmost operand and
a sequence point _before_ all subexpressions of the other operands
and also _before_ all the _operations_ that are parents (or
grandparents, etc) of the sequencing operator subexpression.
Operands or operations not covered by one of these cases for
a particular sequence point may be either before or after
that sequence point.

Now what about:
*(p += i, ++i, p += i) = i++, ++i, i;
Definitely UB-lookingish.

Again I presume you mean

*(p += i, ++i, p += i) = (i++, ++i, i);

but yes both are equally UB. The 'i++' is
after the SP of the last FE, before the SP of
the next FE, before both of the RHS commas,
and before the '=' assignment (which isn't a
sequence point, but still before it), but
is neither definitely before nor definitely
after any of the sequence points of the commas
in the LHS

(p += i, ++i, p += i)

So any of the accesses to 'i' are in conflict with
the 'i++' on the RHS (among other conflicts).

I think what you're getting at is, the notion of "previous
sequence point" and "next sequence point" are well-defined for a
single access but not really well-defined for a pair of accesses.
Unless an access is _definitely after_ the next sequence point of
another access, or _definitely before_ the previous sequence
point of that other access, the two accesses may occur between
the previous sequence point and the next sequence point of the
second access (which terms are now well-defined with respect
to that single access).

 

[Tim Rentsch]

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?

In terms of the abstract machine, it seems clear from 6.3.2.1
paragraphs 1 and 2. What an optimizing compiler might do
isn't relevant, because whatever it does must be faithful
to what the abstract machine does.

 

[Tim Rentsch]

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.

I think you're confused for reasons similar to those explained in my
response to James Dow Allen. Here's an easy way to look at it. Any
change to an object is the result of an operation. Consider each
object-changing operation in turn. This operation has a well-defined
previous sequence point and next sequence point. Now consider all
other accesses (whether reading or writing) to that object. If any of
those accesses are not _definitely before_ the previous sequence point
and not _definitely after_ the next sequence point (of the operation
we started on), then there is undefined behavior. But if all the
other accesses are either definitely before the previous SP, or
definitely after the next SP, and that's true for all object-changing
operations, then there is no undefined behavior.

 

[Tim Rentsch]

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.

You do have to evaluate the RHS of an assignment (and the LHS for that
matter) before making the assignment, but that doesn't make assignment
a sequence point. 6.3.2.1 p 1&2 make it clear that accessing a
variable implies evaluating the expression containing the variable
reference (or any other lvalue object reference). Evaluation is
necessary to get the value stored in the abstract machine.