still problems with ?:

[Doug Gwyn]

In article <4675 at alvin.mcnc.org> spl at mcnc.org.UUCP (Steve Lamont) writes:
>>((a = *p++) && e2 ) || (!a && e3)
>Is right to left evaluation mandated in this case?  It seems to me that
>I've been bitten by things like this before, either by non-standards
>conforming compilers, ambiguous definition in the standard, my own
>stupidity, or all of the above.  In any case, it seems that defensive
>programming might dictate something like ...

There has never been any ambiguity about the correct sequence of
operations during evaluation of such an expression (except when
`p' is used in `e2' or `e3').  The outermost operator is ||; to
evaluate ex1||ex2 the compiler is obliged to generate code that
evaluates ex1 first, and ex2 only if necessary.  To evaluate ex1,
here ((a=*p++)&&e2), the stuff within the outermost parens must
be evaluated.  To evaluate that, the rules require that (a=*p++)
must be evaluated first, and e2 only if necessary. ... If ex2,
here (!a&&e3), is required to be evaluated, that is after ex1 has
been completely evaluated.  There is no ambiguity.

The point of C having assignment expressions, postincrement
operators, short-circuit evaluators, and so forth is precisely
to avoid having to use techniques such as your "defensive
programming" example.  Of course some vendor might offer what is
called a "C compiler" that gets basic expression evaluation wrong,
but if so, it would be virtually useless for the vast majority of
existing C source code.  I don't think you really need to guard
against totally broken compilers; if you start worrying about that,
there is no end to the things that "might" be done wrong..