Velocity Reviews > What is a sequence point?

# What is a sequence point?

Deniz Bahar
Guest
Posts: n/a

 02-11-2005
I know the basic definition of a sequence point (point where all side
statement:

"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 accessed only to determine the
value to be stored."

Can someone give me examples of expressions that "barely" break this
rule (the type a newcomer might trip over)?

If you are between sequence points, then what does that second sentence
mean "prior value"?

Randy Howard
Guest
Posts: n/a

 02-11-2005
In article <(E-Mail Removed) .com>,
http://www.velocityreviews.com/forums/(E-Mail Removed) says...
> I know the basic definition of a sequence point (point where all side
> statement:
>
> "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 accessed only to determine the
> value to be stored."
>
> Can someone give me examples of expressions that "barely" break this
> rule (the type a newcomer might trip over)?
>
> If you are between sequence points, then what does that second sentence
> mean "prior value"?

Specifically,
http://www.eskimo.com/~scs/C-faq/q3.8.html

Also related:
http://www.eskimo.com/~scs/C-faq/q3.1.html
http://www.eskimo.com/~scs/C-faq/q3.2.html
http://www.eskimo.com/~scs/C-faq/q3.3.html
http://www.eskimo.com/~scs/C-faq/q3.9.html

Then read all of it again.

--
"Making it hard to do stupid things often makes it hard
to do smart ones too." -- Andrew Koenig

Deniz Bahar
Guest
Posts: n/a

 02-11-2005

Randy Howard wrote:
> >
> > If you are between sequence points, then what does that second

sentence
> > mean "prior value"?

>
> Specifically,
> http://www.eskimo.com/~scs/C-faq/q3.8.html
>
> Also related:
> http://www.eskimo.com/~scs/C-faq/q3.1.html
> http://www.eskimo.com/~scs/C-faq/q3.2.html
> http://www.eskimo.com/~scs/C-faq/q3.3.html
> http://www.eskimo.com/~scs/C-faq/q3.9.html
>
> Then, read the entire FAQ.
>
> Then read all of it again.
>

I read the FAQ before my original post. It was the FAQ that actually
tickled my mind and made me wonder if I was just lucky all this time
when I was using side effects in expressions.

This sentence from the FAQ really confused me:

"The second sentence can be difficult to understand. It says that if an
object is written to within a full expression, any and all accesses to
it within the same expression must be for the purposes of computing the
value to be written. This rule effectively constrains legal expressions
to those in which the accesses demonstrably precede the modification."

More confused about the FAQ's explanation of the sentence from the
standard than the standard itself. I'm all around confused about side
effect and sequence points :_(

Randy Howard
Guest
Posts: n/a

 02-11-2005
In article <(E-Mail Removed). com>,
(E-Mail Removed) says...
>
> Randy Howard wrote:
> > >
> > > If you are between sequence points, then what does that second

> sentence
> > > mean "prior value"?

> >
> > Specifically,
> > http://www.eskimo.com/~scs/C-faq/q3.8.html
> >
> > Also related:
> > http://www.eskimo.com/~scs/C-faq/q3.1.html
> > http://www.eskimo.com/~scs/C-faq/q3.2.html
> > http://www.eskimo.com/~scs/C-faq/q3.3.html
> > http://www.eskimo.com/~scs/C-faq/q3.9.html
> >
> > Then, read the entire FAQ.
> >
> > Then read all of it again.
> >

>
> I read the FAQ before my original post. It was the FAQ that actually
> tickled my mind and made me wonder if I was just lucky all this time
> when I was using side effects in expressions.

Ok, well, the links after the first one contain specific examples. I
was hoping that one or more of them would turn the lightbulb on for
you because I usually find that examples can be helpful when the legalese
gets overwhelming.

In particular, 3.2 has a more lengthy explanation, and a common example
as well. It seems to explain it pretty well to me, so if that doesn't do
it for you, maybe somebody else can provide a better explanation.

--
"Making it hard to do stupid things often makes it hard
to do smart ones too." -- Andrew Koenig

pete
Guest
Posts: n/a

 02-11-2005
Deniz Bahar wrote:
>
> I know the basic definition of a sequence point (point where all side
> statement:
>
> "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 accessed only to determine the
> value to be stored."
>
> Can someone give me examples of expressions that "barely" break this
> rule (the type a newcomer might trip over)?
>
> If you are between sequence points,
> then what does that second sentence
> mean "prior value"?

(p = p -> next = q)

The above doesn't specify the order of assignment and is undefined.
It could be either (p = q, p -> next = q) or (p -> next = q, p = q).

(i = x[i]++)
The above is being debated on comp.std.c
The i in x[i]++ is evaluated only once, but for two reasons.
It's evaluated to determine the value of the right operand of
the assignment operator, but also to determine the address of
the lvalue of the increment operator.

--
pete

Richard Bos
Guest
Posts: n/a

 02-11-2005
"Deniz Bahar" <(E-Mail Removed)> wrote:

> I know the basic definition of a sequence point (point where all side
> statement:
>
> "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 accessed only to determine the
> value to be stored."
>
> Can someone give me examples of expressions that "barely" break this
> rule (the type a newcomer might trip over)?
>
> If you are between sequence points, then what does that second sentence
> mean "prior value"?

A sequence point is a point in the execution of a program at which all
side effects (that is, all assignments, file output and volatile
accesses) must have been completed. Examples are at the end of a
complete expression, just before a function call, and at the logical,
comma and conditional operators.
The compiler is allowed to "save up" or mix side effects between two
adjacent sequence points, for example if that results in more efficient
code. However, _at_ a sequence point, all side effects must be complete.

This is useful; it allows both

int a,b;
char x[10],y[10];

...
x[a++]=y[b++];

to be compiled efficiently (possibly with both increments being done in
parallel), _and_

if (valid_index(a) && array[a]>cutoff)

to be compiled safely, that is, without the compiler trying to be
efficient by computing array[a] before we're sure a is valid.

It also means (and here we come to your example) that

a[i]=i++;

is invalid code, because i++ is both incremented, _and_ read for another
purpose than the increment. In the sub-expression i++, i is given a new
value; but in the sub-expression a[i], the _prior value_ of i, that is,
its value before the increment, is used to determine which array member
to assign to.

Richard

Luke Wu
Guest
Posts: n/a

 02-11-2005

Deniz Bahar wrote:
> I know the basic definition of a sequence point (point where all side
> statement:
>
> "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 accessed only to determine the
> value to be stored."
>

I don't know where you got that passage from, but this one from the
last C89 draft is a lot more clear:

"[If] an object is modified more than once, or is modified and accessed
other than to determine the new value, between two sequence points [,
undefined behaviour reusults]"

There are two parts to this:

1) An object can't be modified more than once between sequence points:
examples

j = i-- * i--; /* more obvious fault */

j = ++i * ++i; /* less obvious, but still breaches rule */

You might think that the pre-increments are okay because side effects
happen immediately, but it doesn't matter because the literature says
you can't modify an object more than once.

2) Between sequence points, an object can't be modified and accessed
other than to determine it's new value (trickier of the two parts of
the rule).

examples

i = i + 3; this is okay because i is modified (i = ____) and accessed
(rvalue the the left of =) only to determine the new value for the i

(i += 3) * j; this is not okay, because i is modified (i += _-__) and
accessed (rvalue of i later used to multiply with j) for a reason that
isn't to determine the new value of i.

i = (i += 3) * j; this is okay, because i is modified (i += ____) and
is accessed to determine the new value of i (left side i = _____).

a[i++]; this is not okay, because i is modified [i++] then accessed to
determine something other than the new value of i.

I hope this helps.

Luke Wu
Guest
Posts: n/a

 02-11-2005

pete wrote:
> Deniz Bahar wrote:
> >
> > I know the basic definition of a sequence point (point where all

side
> > statement:
> >
> > "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 accessed only to determine

the
> > value to be stored."
> >
> > Can someone give me examples of expressions that "barely" break

this
> > rule (the type a newcomer might trip over)?
> >
> > If you are between sequence points,
> > then what does that second sentence
> > mean "prior value"?

>
> (p = p -> next = q)
>
> The above doesn't specify the order of assignment and is undefined.
> It could be either (p = q, p -> next = q) or (p -> next = q, p = q).

but =assignment operators associate left to right, so it would be:

(p -> next = q, p = q)

>
>
> (i = x[i]++)
> The above is being debated on comp.std.c
> The i in x[i]++ is evaluated only once, but for two reasons.
> It's evaluated to determine the value of the right operand of
> the assignment operator, but also to determine the address of
> the lvalue of the increment operator.
>

this would seem to break the rule, because the postincrement is not an

infobahn
Guest
Posts: n/a

 02-11-2005
Luke Wu wrote:
>
> pete wrote:
> > (p = p -> next = q)
> >
> > The above doesn't specify the order of assignment and is undefined.
> > It could be either (p = q, p -> next = q) or (p -> next = q, p = q).

>
> but =assignment operators associate left to right, so it would be:
>
> (p -> next = q, p = q)

Wrong. Because there's no sequence point, the compiler is free to do
the evaluations in any order it likes. Associativity does not
determine the order of evaluation.

Lawrence Kirby
Guest
Posts: n/a

 02-11-2005
On Fri, 11 Feb 2005 08:08:44 -0800, Luke Wu wrote:

>
> Deniz Bahar wrote:
>> I know the basic definition of a sequence point (point where all side
>> statement:
>>
>> "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 accessed only to determine the
>> value to be stored."
>>

>
>
> I don't know where you got that passage from, but this one from the
> last C89 draft is a lot more clear:

The text is that in the current standard.

> "[If] an object is modified more than once, or is modified and accessed
> other than to determine the new value, between two sequence points [,
> undefined behaviour reusults]"
>
> There are two parts to this:
>
> 1) An object can't be modified more than once between sequence points:
> examples
>
> j = i-- * i--; /* more obvious fault */
>
> j = ++i * ++i; /* less obvious, but still breaches rule */
>
> You might think that the pre-increments are okay because side effects
> happen immediately, but it doesn't matter because the literature says
> you can't modify an object more than once.
>
>
> 2) Between sequence points, an object can't be modified and accessed
> other than to determine it's new value (trickier of the two parts of
> the rule).
>
> examples
>
> i = i + 3; this is okay because i is modified (i = ____) and accessed
> (rvalue the the left of =) only to determine the new value for the i
>
> (i += 3) * j; this is not okay, because i is modified (i += _-__) and
> accessed (rvalue of i later used to multiply with j) for a reason that
> isn't to determine the new value of i.

This is fine. By your logic you couldn't use the result of an assignment
operator for anything. Perhaps this is one reason why the draft text
you cite was corrected?

> i = (i += 3) * j; this is okay, because i is modified (i += ____) and
> is accessed to determine the new value of i (left side i = _____).

i is modified twice between sequence points so this is undefined.

> a[i++]; this is not okay, because i is modified [i++] then accessed to
> determine something other than the new value of i.

Again, this is perfectly fine.

Note that neither assignment nor increment/decrement operators reread the
value of the object after it has been modified.

Lawrence

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post stef mientki Python 13 10-20-2007 10:21 AM =?Utf-8?B?ZnJlZA==?= Wireless Networking 2 12-17-2004 08:27 PM Paul Porcelli Perl 1 07-14-2004 10:52 PM lezah VHDL 0 02-04-2004 04:45 PM bird Computer Support 13 12-24-2003 02:20 AM