i op= bug: is it a bug, and is it REALLY fixed?

qwerty at drutx.UUCP qwerty at drutx.UUCP
Fri Apr 20 02:00:29 AEST 1984


[Is this line necessary]
[Was the above line necessary]

The program at the end of this article was run on a number of different
machines with the following results:

    1	    2	    3	    4	    5	    6
  ----	  ----	  ----	  ----	  ----	  ----
  19 2	  20 2	  20 2	  20 2	  20 2	  19 2
  0 3	  0 3	  20 3	  20 4	  0 3	  19 4
  30 5	  30 5	  30 5	  30 6	  30 5	  30 5
  33 6	  33 6	  30 6	  30 8	  33 6	  30 6

1) Maxi-Unix on an Ahmdahl (sp?), Ver. 5.0
2) Unix on a Vax 11/780, Ver. 5.0
3) Unix on a Dec 11/70, Ver. 3.0 **right answer**
4) Unix on a 3B20, Ver. 5.0
5) Mark Williams Co. C on an Intel 86/330 System, with 8087 support
6) Ancient Yourdon (I think) compiler on a Dec 11/44 **right answer**

(Talk about a chance to test program portability!)

The program checks for both the proper type coercion and the proper
number of side effects from the evaluation(s) of the first expression.
The form E1 = E1 op E2; should cause j to be incremented by two, while
the form E1 op= E2; should produce only a single increment.  Note that
the bug was "fixed" on machine 4, BUT apparently by evaluating
E1 twice, which is also against the "rules".

The other item to note is that the two oldest compilers produced correct
code.  This definitely proves, in all cases, that older is better.:-)

Anyone else out there have some other machines or compilers to try??

/*
 *	Simple E1 op= E2 test
 */
#include	<stdio.h>
main()
	{
	int	i,
		j = 0,
		*ifunc();

	i = 100;
	*ifunc(&i, &j) = *ifunc(&i, &j) * .2;
	printf("%d %d\n", i, j);

	i = 100;
	*ifunc(&i, &j) *= .2;
	printf("%d %d\n", i, j);

	i = 100;
	*ifunc(&i, &j) = *ifunc(&i, &j) / 3.3;
	printf("%d %d\n", i, j);

	i = 100;
	*ifunc(&i, &j) /= 3.3;
	printf("%d %d\n", i, j);
	}

int	*ifunc(a, b)
int	*a, *b;
	{
	++*b;
	return a;
	}

						Brian Jones
						ATTCP
						drutx!qwerty



More information about the Comp.lang.c mailing list