From: Dennis Ritchie <dmr@bell-labs.com>
Subject: Re: Help w/ undefined behavior ( a = a++; )
Date: 27 Mar 1998
Newsgroups: comp.lang.c,comp.std.c

Among other contributors, Nick Maclaren wrote on the perennial
subject of the meaning of sequence points:

 > ... There is a serious ambiguity
 > in the assumption of chronology, which I must check has been fixed
 > in C9X.  It occurs in constructions like:

 >  (a,++a,a)+(a,++a,a)

 > But the original example of 'a = f(a++);' is not a problem.

I think it is worth admitting that sequence points (places
at which side effects become evident) were a useful addition
to the semantic description of the language in C89, but
also that neither it nor (so deeply as I have read) C9X
is fully helpful.

The problem is that the current and proposed standard
seem, at least in places, to assume that there is a total,
temporal ordering (during execution) of sequence points that
can be deduced from the textual ordering of the source
program.  It would have been better to use the term
"partial order" explicitly and say what must come before
what and what's not ordered by the standard.

In particular saying that the  ,  operator induces a sequence
point with respect to its operands (and not necessarily
with respect to a larger expression in which it occurs) might
help.  Likewise--to fiddle the function call example--in

	extern i;
	a[i] = f(i++);

the fact that the argument sequence point implies
that within f's evaluation the increment must be seen
in the extern version of i does not necessarily mean that
the argument sequence point requires any ordering between
the evaluation of the address of a[i] and the i++ of the
argument.

Fully working this out to give concise descriptions of
what's OK and what's not is hard.  The "maximum liberty"
principle would seem to call for a position in which
evaluation of

	f() + g();

admits instruction-by-instruction interleaving of the
two functions, and damn the side-effects, a more radical
posture than anyone wants, even though all sequence
points in f and g are putatively unordered w.r.t. the sum
expression.

Fully functional-type languages in theory don't suffer from
this kind of problem, although in practice of course they
do (just not as obviously).  Languages in which evaluation
order is fully specified don't either.

	Dennis