faqcatee08.html

this is a mirrored site c-faq. thought might need offline

<li>at a function call
(after the evaluation of all the arguments,
and
just before the actual call).
</UL></p><p>The
Standard states that

<blockquote>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.
</blockquote></p><p>
These two rather opaque sentences
say several things.
First,
they talk about operations bounded by
the
``previous and next sequence points'';
such operations
usually correspond to

full expressions.

(In an expression statement,
the ``next sequence point''
is
usually

at the terminating semicolon,
and the ``previous sequence point''

is
at the end of the previous
statement.
An expression may also contain intermediate
sequence points,
as listed above.)
</p><p>The first sentence rules out both the examples

<pre>
	i++ * i++
</pre>
and
<pre>
	i = i++
</pre>
from questions <a href="faqcatee08.html?sec=expr#evalorder2">3.2</a>
and <a href="faqcatee08.html?sec=expr#ieqiplusplus">3.3</a>--in both cases,
<TT>i</TT> has its value modified twice within the expression,
i.e. between sequence points.
(If we were to write a similar expression
which
did

have an internal sequence point,
such as
<pre>
	i++ &amp;&amp; i++
</pre>
it <em>would</em> be well-defined,
if questionably useful.)
</p><p>The second sentence

can be
quite
difficult to understand.
It turns out that it disallows code like
<pre>
	a[i] = i++
</pre>
from question <a href="faqcatee08.html?sec=expr#evalorder1">3.1</a>.
(Actually, the other expressions we've been discussing
are in violation of the second sentence, as well.)
To see why,
let's first look more carefully
at what the Standard is trying to allow and disallow.
</p><p>Clearly,
expressions like
<pre>
	a = b
</pre>
and
<pre>
	c = d + e
</pre>
which read

some values and use them to write others,
are well-defined and

legal.
Clearly,

<a href="../../expr/fn16.html" rel=subdocument>[footnote]</a>
expressions like
<pre>
	i = i++
</pre>
which modify the same value twice
are abominations
which needn't be allowed
(or in any case,
needn't be well-defined,
i.e. we don't have to figure out a way to say what they do,

and compilers don't have to support them).

Expressions
like these
are disallowed by the first sentence.
</p><p>It's also clear
<a href="../../expr/fn16.html" rel=subdocument>[footnote]</a>
that we'd like to disallow expressions like
<pre>
	a[i] = i++
</pre>
which modify <TT>i</TT> <em>and</em> use it along the way,
but not disallow expressions like
<pre>
	i = i + 1
</pre>
which
use and modify <TT>i</TT>

but only modify it
later


when it's reasonably easy to ensure
that the final store of the final value
(into <TT>i</TT>, in this case)
doesn't interfere with

the
earlier
accesses.
</p><p>And that's

what the second sentence says:
if an object is written to within a full expression,
any
and all

accesses to it within the same expression
must be
directly involved in the computation of
the value to be written.
This rule effectively constrains legal expressions
to those in which the accesses demonstrably precede
the
modification.
For example,
the old standby
<TT>i&nbsp;=&nbsp;i&nbsp;+&nbsp;1</TT> is
allowed,
because the access of <TT>i</TT> is used to determine <TT>i</TT>'s final value.
The example
<pre>
	a[i] = i++
</pre>
is disallowed because one of the accesses
of <TT>i</TT>
(the one in <TT>a[i]</TT>)
has nothing to do
with the value which ends up being stored in <TT>i</TT>
(which happens over in <TT>i++</TT>),
and so there's no good way to
define--either for our understanding
or the compiler's--whether the access should take place 
before or after the incremented value is stored.
Since there's no good way to define it,
the Standard declares that it is undefined,
and that portable programs
simply must not use such constructs.
</p><p>See also
questions <a href="faqcatee08.html?sec=expr#evalorder4">3.9</a> and <a href="faqcatee08.html?sec=expr#confused">3.11</a>.
</p>









<p>References:

ISO Sec. 5.1.2.3, Sec. 6.3, Sec. 6.6, Annex C
<br>
Rationale Sec. 2.1.2.3
<br>
H&amp;S Sec. 7.12.1 pp. 228-9
<hr><hr><hr>
<a name="evalorder4">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../expr/evalorder4.html"><!-- qtag -->Question 3.9</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
So
if I write
<pre>
a[i]&nbsp;=&nbsp;i++;</pre>

and I don't care

which cell of <TT>a[]</TT> gets written to,
the code is fine,
and <TT>i</TT> gets
incremented by one,
right?

</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Not necessarily!
For one thing,
if you don't care which cell of <TT>a[]</TT> gets written to,
why write code which seems to write to <TT>a[]</TT> at all?
More significantly,

once
an expression or program becomes undefined,
<em>all</em> aspects of it become undefined.

When an undefined expression has
(apparently)
two plausible interpretations,
do not mislead yourself by imagining
that the compiler will choose one or the other.
The Standard does not require that
a compiler make an obvious choice,
and some compilers don't.
In this case,
not only do we not know
whether <TT>a[i]</TT> or <TT>a[i+1]</TT> is written to,
it is
possible
that a completely unrelated cell of the array
(or any random part of memory)
is written to,
and it is also not possible to predict
what final value <TT>i</TT> will receive.

See questions <a href="faqcatee08.html?sec=expr#evalorder2">3.2</a>,
<a href="faqcatee08.html?sec=expr#ieqiplusplus">3.3</a>,
<a href="faqcat7d4b.html?sec=ansi#undef">11.33</a>,
and
<a href="faqcat7d4b.html?sec=ansi#experiment">11.35</a>.
<hr><hr><hr>
<a name="experiment">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../expr/experiment.html"><!-- qtag -->Question 3.10a</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
People keep saying that the behavior
of <TT>i&nbsp;=&nbsp;i++</TT>
is undefined,
but
I just tried
it
on an ANSI-conforming compiler,
and got the results I expected.
</p>
<p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
See question <a href="faqcat7d4b.html?sec=ansi#experiment">11.35</a>.
<hr><hr><hr>
<a name="expec0">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../expr/expec0.html"><!-- qtag -->Question 3.10b</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
People told me that if I evaluated an undefined expression,
or accessed an uninitialized variable,
I'd get a random, garbage value.
But I tried it, and got <em>zero</em>.
What's up with that?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
It's hard to answer this question,
because it's hard to see
what the

citation of
the ``unexpected'' value of 0 is supposed to prove.
C does guarantee that
certain
values will be initialized to 0
(see question <a href="faqcatd3c2.html?sec=decl#initval">1.30</a>),
but for the rest
(and certainly for the results of those undefined expressions),
it <em>is</em> true that you might get garbage.
The fact that you happened to get 0
one time
does not mean
you were wrong to have expected garbage,
nor does it mean that you can depend on this happening next time
(much less
that you should
write code which depends on it!).
</p><p>Most memory blocks newly delivered by the operating system,
and most as-yet-untouched stack frames,
do tend to be zeroed,
so
the first time you access them,
they may happen to contain 0,
but after a program has run for a while,
these regularities rapidly disappear.
(And programs which unwittingly depend on
a circumstantial initial value of an uninitialized variable
can be <em>very</em> difficult to debug,
because the ``expected'' values may coincidentally arise
in all the small, easy test cases,
while the unexpeccted values and the attendant crashes happen
only in the larger, longer-running, much-harder-to-trace-through invocations.)
<hr><hr><hr>
<a name="confused">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../expr/confused.html"><!-- qtag -->Question 3.11</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
How can I avoid these undefined evaluation order difficulties
if I don't feel like learning the complicated rules?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
The easiest answer
is that if you steer clear of expressions
which don't have
reasonably
obvious
interpretations,
for the most part you'll steer clear of
the undefined ones,
too.
(Of course,
``reasonably obvious''
means different things to different people.
This answer works as long as you agree
that
<TT>a[i]&nbsp;=&nbsp;i++</TT> and <TT>i&nbsp;=&nbsp;i++</TT>
are not ``reasonably obvious.'')
</p><p>To be a bit more precise,
here are some
simpler rules which,
though slightly more conservative than
the ones in the Standard,
will
help to
make sure that your code is
``reasonably obvious''
and
equally understandable to both 
the compiler <em>and</em> your fellow programmers:
<OL><li>Make sure that each
expression
modifies at most one object.
By ``object'' we mean either
a simple variable,
or
a cell of an array,
or
the
location
pointed to by a pointer (e.g. <TT>*p</TT>).
A ``modification'' is either
simple assignment with the <TT>=</TT> operator,
or
a compound assignment
with an operator like <TT>+=</TT>, <TT>-=</TT>, or <TT>*=</TT>,
or an increment or decrement with <TT>++</TT> or <TT>--</TT>
(in either pre or post forms).
<li>If an object
(as defined above)
appears more than once in an expression,
and is the object modified in the expression,
make sure that
<em>all</em> appearances of the object
which fetch its value
participate in the computation of the new value which is stored.
This rule allows the expression
<pre>
	i = i + 1
</pre>
because although the object <TT>i</TT> appears twice and is modified,
the appearance 
(on the right-hand side)
which fetches <TT>i</TT>'s old value
is used to compute <TT>i</TT>'s new value.
<li>If you want to break rule 1,
make sure that the several objects being modified are distinctly different,

and try to limit yourself to two or at most three modifications,
and of a style matching those of the following examples.
(Also,
make sure that you continue to follow rule 2

for each object modified.)

The expression
<pre>
	c = *p++
</pre>
is allowed under this rule,
because the two objects modified 
(<TT>c</TT> and <TT>p</TT>)
are distinct.
The expression
<pre>
	*p++ = c
</pre>
is also allowed,
because <TT>p</TT> and <TT>*p</TT>
(i.e. <TT>p</TT> itself and what it points to)
are both modified but are almost certainly distinct.
Similarly, both
<pre>
	c = a[i++]
and
	a[i++] = c
</pre>
are allowed,
because <TT>c</TT>, <TT>i</TT>, and <TT>a[i]</TT> are
presumably

all distinct.
Finally, expressions like
<pre>
	*p++ = *q++
</pre>
and
<pre>
	a[i++] = b[j++]
</pre>
in which <em>three</em> things are modified
(<TT>p</TT>, <TT>q</TT>, and <TT>*p</TT> in the first expression,
and <TT>i</TT>, <TT>j</TT>, and <TT>a[i]</TT> in the second),
are allowed <em>if</em> all three objects are distinct,
i.e. only if two <em>different</em> pointers <TT>p</TT> and <TT>q</TT>
or two <em>different</em> array indices <TT>i</TT> and <TT>j</TT>
are used.
<li>You may also break rule 1 or 2
as long as you interpose
a defined sequence point operator
between the two modifications,
or between the modification and the access.
The expression
<pre>
	(c = getchar()) != EOF &amp;&amp; c != '\n'
</pre>
(commonly seen in a <TT>while</TT> loop while
reading a line)
is legal because
the second access of the variable <TT>c</TT>
occurs after the sequence point implied by <TT>&amp;&amp;</TT>.
(Without the sequence point,
the expression would be illegal
because the access of <TT>c</TT> while comparing it to <TT>'\n'</TT>
on the right
does

not ``determine the value to be stored''
on the left.)
<hr><hr><hr>
<a name="prevspost">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../expr/prevspost.html"><!-- qtag -->Question 3.12a</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What's the difference between <TT>++i</TT> and <TT>i++</TT>?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
If your C book doesn't explain, get a better one.
Briefly:
<TT>++i</TT> adds one to
the stored value of
<TT>i</TT>
and ``returns'' the
new,
incremented value
to the surrounding expression;
<TT>i++</TT>
adds one
to <TT>i</TT> but
returns the prior, unincremented value.


<hr><hr><hr>
<a name="plusplus">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../expr/plusplus.html"><!-- qtag -->Question 3.12b</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
If I'm not using the value of the expression,
should I use <TT>++i</TT> or <TT>i++</TT> to increment a variable?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Since the two forms differ only in the value yielded,
they are entirely equivalent when only their side effect is needed.
(However, the prefix form is preferred in C++.)
Some people will tell you that in the old days one form was preferred
over the other because it utilized a PDP-11 autoincrement
addressing mode,
but those people are confused.

An autoincrement addressing mode can only help if a pointer
variable is being incremented and indirected upon,
as in
<pre>
	register char c, *cp;
	c = *cp++;
</pre>

See also question <a href="faqcatee08.html?sec=expr#ieqiplusplus">3.3</a>.
</p>