Article View: comp.sys.sequent
Article #268sequent C *=
From: Jim Nelson
Date: Thu, 07 Jun 1990 23:33
Date: Thu, 07 Jun 1990 23:33
62 lines
2734 bytes
2734 bytes
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
Technical Details
Message-ID:
<837@uncw.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!uwm.edu!psuvax1!rutgers!mcnc!ecsgate!ecsvax!uncw!nelsonShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!uwm.edu!psuvax1!rutgers!mcnc!ecsgate!ecsvax!uncw!nelson From: nelson@uncw.UUCP (Jim Nelson) Newsgroups: comp.sys.sequent Subject: sequent C *= Message-ID: <837@uncw.UUCP> Date: 7 Jun 90 23:33:26 GMT Reply-To: nelson@uncw.UUCP (Jim Nelson) Organization: Univ. N. C. at Wilmington, CS & Math Dept. Lines: 62