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

[Ian! D. Allen [CGL]]

In article <1991Mar31.214127.5224 at pslu1.psl.wisc.edu>, khan at pslu1.psl.wisc.edu (Mumit Khan) writes:
> 
>  ---------------- MIPS C bug in post-increment of variables ----------
>  MACHINE = DS3100
>  OS = ULTRIX V4.1 (Rev. 52) System #1: Wed Dec 19 15:20:46 CST 1990
>       UWS V4.1 (Rev. 197)
> 
> 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++))().

This is not 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.  Many compilers will do it *before* the function call,
but it is not required.

> ------------------------ START OF PROGRAM ---------------------------
> #include <stdio.h>
> 
> typedef int (*Inst)();
> #define StopInst (Inst) 0
> static int dummy ();
> static Inst machine[] = {dummy, dummy, dummy, dummy, dummy, StopInst};
> static Inst *pc = NULL;
> 
> main () {
>     extern int start;
>     fprintf (stderr, "Starting pc: %x\n", pc = machine);
>     for (; *pc != StopInst;)
> 	(*(*pc++)) ();		/* BUG BUG BUG BUG BUG BUG BUG */
> }
> static int dummy () {
>     extern Inst *pc;
>     fprintf (stderr, "PC (in dummy): %x\n", pc);
>     return 0;
> }
> 
> 
> ------------------------- END OF PROGRAM ------------------------
> 
> OUTPUT FROM MIPS CC. (Version 2.1)
> > bug-mips-cc
> 
> Starting pc: 10000430
> PC (in dummy): 10000430			<--- NOTE *NO* INCREMENT
> PC (in dummy): 10000434
> PC (in dummy): 10000438
> PC (in dummy): 1000043c
> PC (in dummy): 10000440
>  
> 
> OUTPUT FROM MIPS GCC. (Version 2.1)
> > gcc -v
> gcc version 1.37.1 OSF 1.9.2.14 Ultrix Dec Mips Dec 29 1990
> > bug-mips-gcc
> 
> Starting pc: 10000460
> PC (in dummy): 10000464			<--- NOTE INCREMENT
> PC (in dummy): 10000468
> PC (in dummy): 1000046c
> PC (in dummy): 10000470
> PC (in dummy): 10000474
> 
> 
> OUTPUT FROM SparcStation (IPC) CC. (SunOS rel. 4.1.1)
> > bug-sun4-cc
> 
> Starting pc: 40a8
> PC (in dummy): 40ac 			<--- NOTE INCREMENT
> PC (in dummy): 40b0
> PC (in dummy): 40b4
> PC (in dummy): 40b8
> PC (in dummy): 40bc
> 
> ---------------------------------------------------------------------

I quote from someone who read the ANSI book:

From: giguere at csg.uwaterloo.ca (Eric Giguere)
Subject: Re: Autoincrement in function calls; when?
Organization: University of Waterloo

In article <1991Apr9.143020.3504 at watcgl.waterloo.edu> "Ian! D. Allen [CGL]" <idallen at watcgl.waterloo.edu> writes:
>Someone claims this is a bug, but I think it's just the way C works.
>
>>Newsgroups: comp.unix.ultrix
>>Subject: auto-increment bug in Ultrix(4.1) C (DS3100)
>>
>>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++))().

Interesting problem.  Best to go straight to the horse's mouth on this
one, the ANSI Standard:                       

	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.

Hmmm... so what's a 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.  Hence within the function call

                (*(*pc++))()

the value of pc is implementation-defined.  Congratulations, Ian!, you
can pick up your prize at....

-- 
Eric Giguere                                       giguere at csg.UWaterloo.CA
           Unlike the cleaning lady, I have to do Windows.
-- 
-IAN! (Ian! D. Allen) idallen at watcgl.uwaterloo.ca idallen at watcgl.waterloo.edu
 [129.97.128.64]  Computer Graphics Lab/University of Waterloo/Ontario/Canada