still problems with ?:
Doug Gwyn
gwyn at smoke.BRL.MIL
Sat Jun 10 01:33:36 AEST 1989
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..
More information about the Comp.lang.c
mailing list