auto-increment bug in Ultrix(4.1) C (DS3100)

[Lasse H Oestergaard EMP]

diamond at jit345.swstokyo.dec.com (Norman Diamond) writes:

>In article <1991Apr15.161123.16353 at watcgl.waterloo.edu> idallen at watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes:
>>In article <1991Mar31.214127.5224 at pslu1.psl.wisc.edu>, khan at pslu1.psl.wisc.edu (Mumit Khan) writes:
>>> Note the output from the following program in various cases. MIPS C is 
>>> the only one causing the problem (of not incrementing the global shared
>>> variable "pc" in the call (*(*pc++))().
>[...]
>>> typedef int (*Inst)();
>>> static Inst *pc = NULL;
>>> 	(*(*pc++)) ();		/* BUG BUG BUG BUG BUG BUG BUG */

>>This is not a bug.

>Well, Mumit Khan is using a compiler that does not claim ANSI conformance,
>and complaining that the result is not ANSI conformant.  This makes the
>complaint partly meaningless.

>(However, quality of implementation might possibly be a consideration even
>for non-conformant compilers.  Disclaimer:  Although I do not know if this
>is possible or not, my employer is not the one suggesting it.)

>For an ANSI-conformant compiler, it would indeed be a bug.

>>The C Language does not require the increment to happen until the end of
>>the expression, that is, until *after* the function call.
>>I quote from someone who read the ANSI book:
>>From: giguere at csg.uwaterloo.ca (Eric Giguere)
>>	Section 3.3.2.4:
>>        The side effect of updating the stored value of the operand
>>        shall occur between the previous and the next sequence point.
>>	Section 2.1.2.3:
>>        At certain specified points in the execution sequence called
>>        sequence points, all side effects of previous evaluations shall
>>        be complete and no side effects of subsequent evaluations shall
>>        have taken place.
>>    Section 3.6:
>>        The end of a full expression is a sequence point.
>>    Section 3.3:
>>        Between the previous and next sequence point an object shall
>>        have its stored value modified at most once by the evaluation
>>        of an expression.
>>So what can we conclude?  Only that the increment has to have taken effect
>>by the end of the expression.
>>Congratulations, Ian!, you can pick up your prize at....

>Messrs. !Allen and Giguere win booby prizes on this one.
>There are also sequence points at some other places, too.  For example:
>     Section 3.3.2.2, page 42, line 21:
>         ... but there is a sequence point before the actual call.

>If the compiler in this case had claimed ANSI conformance, then its
>implementors would also deserve booby prizes.  (Disclaimer:  this is 
>not my employer's opinion.)
>--
>Norman Diamond       diamond at tkov50.enet.dec.com
>If this were the company's opinion, I wouldn't be allowed to post it.

  Try looking at the INDEX in the standard. That will, in addition to the
abovementioned references, point you to  APPENDIX A.2, which states
(quoted in full, since people don't seem to know this, very important,
 definition):

    The following is the sequence points described in paragraph 2.1.2.3.

    . The call to a function, after the arguments have been evaluated
      (paragraph 3.3.2.2)

    . The end of the first operand of the following operators:
      logical AND  &&  (paragraph 3.3.13); logical OR  ||  (paragraph
      3.3.14); conditional ?  (paragraph 3.3.15); comma , (paragraph
      3.3.17).

    . The end of a full expression: An initializer (paragraph 3.5.7);
      the expression in an expression statement (paragraph 3.6.3);
      the controlling expression of a selection statement (if  or
      switch) (paragraph 3.6.4); the controlling expression of a  while
      or  do  statement (paragraph 3.6.5); each of the 3 expressions of
      a  for  statement (paragraph 3.6.5.3); the expression in a
       return  statement (paragraph 3.6.6.4).

End of quote.

Now, together with paragraph 2.1.2.3 (see included articles), the first of 
the above rules quite clearly requires a compliant compiler to do the
increment BEFORE the call.
  That seems more important than handing out wisecracks and booby prizes.
  Unfortunately KERNIGHAN and RITCHIE (even in the 2.d, so called ANSI,
compliant !? edition) mostly ignores this problem, which possibly is the 
cause of the misstatements seen in the previous articles.

Lasse H. Oestergaard          lhoe at id.dth.dk