[comp.sys.sequent] sequent C *=

nelson@uncw.UUCP (Jim Nelson) (06/08/90)

In trying to put up Galactic Bloodshed 3, I ran across this
"interesting" :-( oddity:

>Script started on Thu Jun  7 19:06:44 1990
>% cat /etc/motd
>DYNIX(R) V3.0.14  #3 (nelson): Wed Oct 12 16:36:06 PDT 1988
>% cat damn.c
>main()
>{
>        int i=9, j=9;
>        double z = 9.0;
>        char c = 9;
>        i *= 0.7; /* <----- this will make i==0 on sequent*/
>        /* but every other compiler I tried "gets it right" (i==6) */
>        j = j * 0.7; /*this is ok*/
>        z *= 0.7;
>        printf("i=%d j=%d z=%lf\n",i,j,z);
>}
>% cc damn.c
>"damn.c", line 6: warning: INT op= REAL implemented as INT = INT op (int)REAL
>% a.out
>i=0 j=6 z=6.300000
>% ^D
>script done on Thu Jun  7 19:07:20 1990

Now I know that on p. 7 of the 87/07/31 Rev 1.35 manual for the
Sequent C compiler, it says " ... This is not always true.  An
exception occurs because the type of an assignment _operator_ is
the type of its left side while the type of a normal operator
depends on the rules of conversion. ..."
(underscores mine)

I find in K&R1, on p. 191, the following: " ... the type of an
assignment _expression_ is that of its left operand.", and a little
further down:
	"  assignment-expression:
			...
			lvalue *= expression
			...
		"
(underscores mine)
Does this mean that the words "operator" and "expression" are
equivalent, or is this just some compiler writer's idea of a
joke?

I compiled this code on several other compilers (mostly pcc based,
I guess), and they all "got it right".  Why did Sequent's compiler
writer(s) decide to be different?  What does the standard say?
I realize the compiler in question was written before the standard.
Has anybody else been bitten by this "feature/bug"?  (At least,
to his/her/their credit, the WARNING message is put out, rather
than being silent and smug).
BTW: this is a Balance, not a Symmetry!
Announcing the first annual grep/sed/awk/perl/etc. contest to
convert *= and/or /= operators to the "equivalent" 
E1 =  E1 op (E2)  (again quoting from p. 191 of K&R1).

This is not a flame at Sequent.  Love the hardware ... :-)
-- 
Jim Nelson,UNC-Wilmington,Mathematical Sciences,Wilmington NC 28403
919-395-3300   nelson@ecsvax.uncecs.edu or nelson@ecsvax.bitnet  
{...,mcnc}!ecsvax!nelson or {...,mcnc}!ecsvax!uncw!nelson