What is a sequence point?

[Deniz Bahar]

I know the basic definition of a sequence point (point where all side
effects guaranteed to be finished), but I am confused about this
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"?

[Tim Rentsch]

CBFalconer <cb********@yahoo.com> writes:

infobahn wrote:

Luke Wu wrote:

infobahn wrote: [redundant quoting snipped]
(p = (p->next = q))

Now, whether p->next or q evaluates first is unspecified. But it
doesn't matter, p->next = q happens before p = p->next
The evaluations of p, p->next, and q can happen in any order.

However p->next is never evaluated, it is simply stored into.

It's true that a compiler need not emit any code specifically for the
expression 'p->next'. But in the abstract machine 'p->next' is
evaluated. Looking at the semantics of the '->' operator in section
6.5.2.3, p4:

A postfix expression followed by the -> operator and an identifier
designates a member of a structure or union object. The value is
that of the named member of the object to which the first
expression points, and is an lvalue.

In the abstract machine, it is evaluating the expression that yields
its value. Also, expressions that are lvalue's are evaluated:
section 6.3.2.1, p1, says

An lvalue is an expression with an object type or an incomplete
type other than void; if an lvalue does not designate an object
when it is evaluated, the behavior is undefined.

Evaluating an lvalue does not mean getting the stored value; that
is discussed separately, in 6.3.2.1, p2:

Except when it is the operand of the sizeof operator, the unary &
operator, the ++ operator, the --operator, or the left operand of
the . operator or an assignment operator, an lvalue that does not
have array type is converted to the value stored in the designated
object (and is no longer an lvalue).

The
thing that is evaluated is (p->next = q).
The expression '(p->next = q)' is also evaluated. That evaluation
both yields the value and produces the side effect. The side effect
might not complete until later, but it is produced by evaluating the
expression - section 5.1.3.2.

I don't think this makes
any difference to the argument, because there is no argument about
what gets stored in p. The argument would be about where the
storage into (p->next) goes, and that is what is undefined here.

Of the various people responding to the 'p = p->next = q;' question,
only Chris Torek was conscientious enough to note the discussions in
comp.std.c on this and related topics. Rather than get into those
arguments again here, anyone interested is invited to see the
discussions in comp.std.c, which are still going on.

Incidentally, even if one admits the possibility that the evaluation
of the containing expression 'p = p->next = q' might precede the
evaluation of the contained expression 'p->next = q' (which question
is still being debated), evaluation order is only "unspecified", not
"undefined".

[Mark McIntyre]

On Wed, 16 Feb 2005 19:10:29 +0100, in comp.lang.c , Jirka Klaue
<jk****@tkn.tu-berlin.de> wrote:

Mark McIntyre wrote:

Tim Rentsch wrote:

...

Indeed the program must behave as if 'a + b' is evaluated first.

Indeed, but the point is, it can actually evaluate b+c first. The OP
thought it always did a+b, which is erroneous.

Is it? Doesn't 5.1.2.3#14 explicitly forbid this possibility?

???

it explicitly allows it:

"However, on a machine in which overflow silently generates some value and
where positive and negative overflows cancel, the above expression
statement can be rewritten by the implementation in any of the above ways
because the same result will occur."

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On 16 Feb 2005 10:57:23 -0800, in comp.lang.c , Tim Rentsch
<tx*@alumnus.caltech.edu> wrote:

Actually it does mean unspecified behavior.
I'm unconvinced. I take the word "provides" to mean "provides" rather than
"allows". The two words are different and I suspect you're thinking of
"provides for".
If we look in Annex J
Annex J is informative and thus not gospel.
Furthermore, the word "provides" is used not in the sense of "states"
but in the sense of "allows" or "affords" (as is illustrated in the
sentence "A blanket provides warmth", for example).

Euh, in that sentence, the word means "gives". Not "permits you to have".

But this is a discussion for comp.std.c methinks. Either way, the behaviour
isn't specified by the standard....
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Tim Rentsch]

Mark McIntyre <ma**********@spamcop.net> writes:

On 16 Feb 2005 10:57:23 -0800, in comp.lang.c , Tim Rentsch
<tx*@alumnus.caltech.edu> wrote:

Actually it [referring to 6.5.2.2 p10] does mean
unspecified behavior.
I'm unconvinced.

Hmmm. 6.5.2.2 p10 says

The order of evaluation of the function designator, the actual
arguments, and subexpressions within the actual arguments is
unspecified, but there is a sequence point before the actual
call.

Nothing else in 6.5.2.2 says anything using the word "unspecified".
Earlier, 3.4.4 p1-2, defining "unspecified behavior", says

3.4.4
unspecified behavior
behavior where this International Standard provides two or more
possibilities and imposes no further requirements on which is
chosen in any instance

EXAMPLE An example of unspecified behavior is the order in
which the arguments to a function are evaluated.

Those two together don't convince you that the word "unspecified" in
6.5.2.2 p10 is supposed to mean "unspecified behavior"? I'm at a loss
to see how a reasonable person could reach any other conclusion.

If we look in Annex J

Annex J is informative and thus not gospel.

That's true, Annex J is informative rather than normative. But all
the evidence I'm aware of - 3.4.4, 6.5.2.2, J.1 - all support the
conclusion that use of the term "unspecified" is meant to be
synonymous with "unspecified behavior". Is there even a scintilla of
evidence that the word "unspecified" is ever used in the standard to
mean something other than "unspecified behavior"?
[repeated, rearranged for context]

Furthermore, the word "provides" is used not in the sense of "states"
but in the sense of "allows" or "affords"
I take the word "provides" to mean "provides" rather than
"allows". The two words are different and I suspect you're thinking of
"provides for".

No, I wasn't. The "provides for" phrasing is the intransitive use of
provides, and clearly the transitive is what's meant here. See for
example the online Merriam-Webster's dictionary, which gives AFFORDS
as one of the principal meanings for the transitive verb "provide".
Actually the sense that probably comes closest is "2 a : to supply or
make available"; the point I was trying to make is that the providing
is usually done implicitly rather than by explicit listing of possible
behaviors.

Furthermore, the word "provides" is used not in the sense of "states"
but in the sense of "allows" or "affords" (as is illustrated in the
sentence "A blanket provides warmth", for example).

Euh, in that sentence, the word means "gives". Not "permits you to have".

No, it doesn't. Blankets don't *give* warmth (unless someone was talking
about electric blankets, which I wasn't). Blankets do *afford* warmth.

But this is a discussion for comp.std.c methinks.
Yes, it does seem like it's reached the point where it could
benefit from that audience.

Either way, the behaviour isn't specified by the standard....

Behavior that is "unspecified behavior" still isn't totally
unconstrained; the unspecified behavior that occurs must still be one
of the behaviors that the standard otherwise provides (ignoring for
the moment whether "provides" is meant in the sense of "explicitly
states" or "implicitly supplies"). So if, as I contend, this is a
case of unspecified behavior, that still doesn't mean any behavior is
possible - it must be a behavior that is provided by the standard.

If the meaning is not "unspecified behavior" but simply "unspecified"
(whatever that might mean), and there is no explicit definition of
behavior, then by section 4 p2, it is "undefined behavior". There is
no middle ground where the behavior is completely not specified yet
isn't undefined.