j wrote:
In a footnote in the c99 standard the following is labeled as
undefined:
a[i++] = i;
And in the second clause of section 6.5 the following is stated:
"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 read only to determine the value
to be stored. 70)"
So my question is, how do they derive undefined behaviour from "a[i++]
= i;" ?
With, a[i++] = i; this is one expression and there is only one
sequence point here, ';'.
'i' has its value modified only once and that is in the subscript
operator to designate which object the value of 'i', on the right side
of the assignment operator, will be stored at.
But, I am guessing I am missing something here. So if anyone could
enlighten me it would be much appreciated :)
It's the "furthermor e" part that bites you here.
The `i' on the right-hand side retrieves the value stored
in the variable `i', correct? And is this retrieval for the
purpose of determining what new value to store into `i'? No,
it is not: the value retrieved is intended to be stored somewhere
in the `a' array (but, because of U.B., there's no telling what
might actually happen). So the right-hand-side use of `i' falls
afoul of the "furthermor e," and you've got trouble.
Why the strange restriction? Because the Standard allows
the side-effect of incrementing `i' to occur *anywhere* between
the sequence point prior to this statement and the sequence
point at the end. It might be the very first thing that happens,
it might be the very last, it might even happen in parallel with
other activities. That being the case, there's just no way to
say what value the right-hand-side evaluation of `i' should
produce, or even whether it *can* produce a meaningful value
(think of 32-bit `long' on an 8-bit machine, where the operation
of storing the new value might take several cycles).
Of course, this "fuzziness" about the value doesn't extend
to the `i++' on the left-hand side, if used in isolation. This
sub-expression is required to yield the old value of `i', but
the compiler can indulge in whatever sleight-of-hand it feels
like to get this to occur. For example, it might rewrite the
sub-expression as `(a - 1)[++i]' if that leads to smaller or
faster code. There's just no telling when (between one sequence
point and the next) the incrementation side-effect will become
"visible" to the world at large.
Also, what is the difference between unspecified behaviour and
undefined behaviour? The standard attempts to make a distinction
between the two in Annex J but my dictionary gives the same definition
for "unspecifie d" and "undefined" so I fail to see how they can be
used to describe certain things as though they were different.
The Standard uses these words (and others) in a restricted
and specialized sense because it needs more precision than is
afforded by ordinary English. Other fields of discourse also
use ordinary words in specialized ways -- for example, a "field"
means rather different things to farmers, mathematicians, and
footballers. In Humpty Dumpty's phrase, "When I use a word, it
means exactly what I wan it to mean-- neither more nor less. It's
a question of who's to be master, that's all."
The Standard gives its particular definitions of these terms
in sections 3.4.3 and 3.4.4, and you're welcome to ponder them
there. Informally,
- For "unspecifie d" behavior, the Standard enumerates all
the permissible behaviors but doesn't say which of them
might actually occur. You know you'll get either A or
B or C, but not which -- and you might not get the same
one next time, either. However, you won't get X.
- For "undefined" behavior, the Standard specifies nothing
at all. You cannot assume the result will be A, B, or C;
anything at all could happen: you could get X, or Y, or
the program could halt, or chocolate pudding could ooze
from your keyboard -- or, of course, you could get A.
Nothing prevents a particular implementation from specifying
what the Standard leaves unspecified or defining what the Standard
leaves undefined. A particular implementation might specify that
all operands are evaluated left-to-right, which would make the
behavior of `a[i++] = i' perfectly well-defined -- but only for
that implementation, of course. Another might actually define
`a[i++] = i' as causing demons to fly from your nose -- and much
as I might admire their technical expertise, I have absolutely
no desire to meet the people responsible for that outcome ...
--
Er*********@sun .com 
