Re: sequence points in subexpressions

James Dow Allen wrote:
On Dec 14, 2:20 am, Flash Gordon <s...@xxxxxxxxxxxxxxxxx> 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...@xxxxxxxxxxxxxxxxxxxxxxxx> 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
.

Relevant Pages

  • Re: sequence points in subexpressions
    ... It may be hard to imagine how the C system ... The commas at left separate left-side sequence points, ... while OP's query *does* represent a defining corner- ...
    (comp.lang.c)
  • Re: Felsenstein v. Dembski
    ... fact take on a fairly uniform distribution throughout sequence space. ... can explain the similarities of such a pattern quite well. ... the mechanism of RM/NS has really problems when it comes to explaining ... I imagine what could have existed upon consideration of reasonable ...
    (talk.origins)
  • Re: Benefit of not defining the order of execution
    ... expressions. ... operator and with the comma operator. ... would currently result in undefined behavior. ... separators and as sequence points so that this would be equivalent: ...
    (comp.lang.c)
  • Re: Further along the evaluation order: Was: Order of evaluation.
    ... >attempt to gain a better understanding. ... >I presume that is also undefined since i is modified and fetched in order to ... As I just learned, the comma operator ... introduces a sequence point. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Ultimate debunking of Cantors Theory
    ... But supposed I hadn't mentioned a sequence, ... there is nothing wrong with the set notation here. ... defining and proving things which you heretofor took for granted. ... must be careful to avoind circular reasoning in doing so. ...
    (sci.math)