Re: sequence points in subexpressions

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).

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...@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.

James Dow Allen
.

Relevant Pages

  • Re: sequence points in subexpressions
    ... It may be hard to imagine how the C system ... 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. ... while OP's query *does* represent a defining corner- ...
    (comp.lang.c)
  • Re: sequence points in subexpressions
    ... It may be hard to imagine how the C system ... For those who think commas are permitted, ... end-of-full-expression puts a sequence point after all the ... puts a sequence point before all the subexpressions in the tree). ...
    (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: The Free Market Compared to Yoke of Tyranny
    ... there's no real reason we need the government to come bitching ... Now imagine you want to do any DIY around the house without ... Imagine you buy a pint of beer and what appears in front ... defining and enforcing specific definitions. ...
    (alt.smokers.cigars)
  • Re: infinity
    ... >>> Since 'sequence' implies that each item in the sequence is ... >>> followed by a unique 'next' item, can TO imagine what is the ... David Kastrup, Kriemhildstr. ...
    (sci.math)