Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!decwrl!pa.dec.com!jrdzzz.jrd.dec.com!tkou02.enet.dec.com!jit345!diamond
From: diamond@jit345.swstokyo.dec.com (Norman Diamond)
Newsgroups: comp.unix.ultrix
Subject: Re: auto-increment bug in Ultrix(4.1) C (DS3100)
Message-ID: <1991Apr16.085545.2155@tkou02.enet.dec.com>
Date: 16 Apr 91 08:55:45 GMT
References: <1991Mar31.214127.5224@pslu1.psl.wisc.edu> <1991Apr15.161123.16353@watcgl.waterloo.edu>
Sender: usenet@tkou02.enet.dec.com (USENET News System)
Reply-To: diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Lines: 55

In article <1991Apr15.161123.16353@watcgl.waterloo.edu> idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes:
>In article <1991Mar31.214127.5224@pslu1.psl.wisc.edu>, khan@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@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@tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.