No sequence points in assignment

[Tom Karzes]

In article <5059 at merlin.usc.edu> jeenglis at nunki.usc.edu (Joe English) writes:
-karzes at mfci.UUCP (Tom Karzes) writes:
->
->    x = a + (x = b);
->
->Could the assignment for (x = b) be performed after the outer
->assignment?
-
-As far as I know, yes.  I have a question, though:  Does it really
-matter?  There seems to be a lot of traffic lately asking questions
-like:  "Will (obviously buggy and weird code) work like you would
-expect it to, or is the compiler allowed to do something other than
-What I Mean?" 
-
-I fail to see how these questions are relevant, unless you're trying to
-write incredibly hairy expressions like using a temporary variable
-multiple times in a single expression.  (Which you probably shouldn't
-be doing in the first place!)

I believe it is important to be able to take any sequence of input code
to a compiler and be able to classify its behavior into one of the following
ways:

    1.  It is legal, and the results will be the following, or
        one of the following.

    2.  It is syntactically legal, but is illegal code because it
        violates a certain restriction.  The compiler may give an error
        or warning if it can detect it at compile time, otherwise the
        results are undefined and the compiler is free to do as it wishes.

    3.  It is syntactically illegal.  A compile time error should
        be given.

This is a major goal of any good language standard, and is invaluable to
anyone attempting to implement a language.  It also serves as a useful
guide to anyone using a given language to help them determine whether
they are writing truly portable code or whether they just "got lucky"
on the machine they were using.

The lack of a complete specification in the original C reference manual
has been the cause of much grief on the part of compiler writers and C
programmers alike.  There are many places where you have to read between
the lines, and many places where you have no choice but to try it on the
pcc compiler to see what it does.  For this reason, it is extremely
difficult to write a C compiler from scratch and have it support all
of the little undocumented features of a pcc derived compiler (unless
you happen to know about all of those features in advance).

I'm not trying to justify the example I gave as being reasonable code,
and in fact in my opinion it is not.  However, it is not unreasonable
to expect to be able to answer the question of whether or not it is
legal, and if so what its defined behavior is.  Trying to arbitrarily
draw a line between "reasonable" and "unreasonable" is an unachievable,
and hence useless, goal.  It is hopeless to try to guarantee that you
have documented and supported all "reasonable" constructs in a language
and that anything not explicitly addressed is probably "unreasonable".
This just invites people to see what it does on their system and to
then assume it is supported behavior.  This is one of the mistakes
that the original C implementors made (and in fact I'm not certain
that Dennis appreciates this mistake even to this day, although I
may be wrong about that).