Evaluation of if's
Tim McDaniel
mcdaniel at adi.com
Fri Jun 7 23:31:18 AEST 1991
In article <1991Jun7.011938.11342 at wdl1.wdl.loral.com>
bard at cutter.ssd.loral.com (J H Woodyatt) writes:
I might submit to you that all bets are off concerning the value stored
in `i' after the expression is evaluated, but as for the result of the
expression, if *that* is undefined, then it isn't by any means intuitive.
(*) Not intuitive *to Mr. Woodyatt*. *I* find the ANSI C rule quite
intuitive.
(*) Who says that anything in C has to be "intuitive"? I suggest that
one better guideline is "simple to remember", which is related to
but not the same as "intuitive".
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
accessed only to determine the value to be stored.
[ANS C, section 3.3]
is simple to remember.
(*) For the code in question, the code sequence (for a hypothetical
memory-to-memory machine)
MOV.I &i,#1
MOV.I &i,#2
CMP &i,&i
is intuitive to me, and certainly legal by the standard. The
intent of the standard is that compiler don't have to worry about
multiple assignments between sequence points -- a considerable
freedom.
What about
(*p = 1) == (*q = 2)
? It could take a lot of compiler work, in the general case, to
get what Mr. Woodyatt call the "intuitive" result. Code that uses
pointers could be utterly crippled (rather than partially
crippled on parallel machines, as is the case in C now).
--
"Of course he has a knife; he always has a knife. We all have knives.
It's 1183 and we're barbarians."
Tim McDaniel Applied Dynamics Int'l.; Ann Arbor, Michigan, USA
Internet: mcdaniel at adi.com UUCP: {uunet,sharkey}!amara!mcdaniel
More information about the Comp.lang.c
mailing list