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