powell@decwrl.UUCP (01/03/84)
From: powell (Mike Powell)
The DEC VMS C compiler does the correct (according to K&R) thing (i.e., treats
it as integer = integer * float). Apparently the implementors read the book,
rather than the portable C compiler. Are there a lot of differences between
K&R and pcc? Have these caused problems in Unix ports when a new compiler was
written?
Michael L. Powell
Western Research Laboratory
Digital Equipment Corporation
Los Altos, CA
{decvax,ucbvax}!decwrl!powellstevesu@azure.UUCP (Steve Summit) (01/04/84)
It just goes to show, always type your code explicitly.
Shun implicit declarations or type conversions -- they'll get you
in the end.
Steve Summit
tektronix!tekmdp!stevesuedhall@randvax.ARPA (Ed Hall) (01/06/84)
------------------------------ We have tried integer *= float with 5 different C compilers, and all of them convert the float before the multiplication: 1) PCC on the VAX, 2) CC on the PDP-11 (i.e., the Ritchie compiler), 3) the UniSoft C compiler on the CYB, 4) AZTEC C on the APPLE, 5) C-86 on the IBM PC (Computer Innovations). I've seen at least two cases where code was broken due to this counter-intuitive behavior. A `fix' to PCC is not particularly difficult (at least for the VAX); I have one, but won't post it until this question is settled. Thus, the VMS C compiler seems to be in the minority. If the Ritchie compiler is considered to be the `reference', then it would seem that C does the counter-intuitive thing. But reading the appropriate part of K&R numerous times leaves me with the clear impression that the conversion belongs after the operation and before the store. -Ed Hall decvax!randvax!edhall
edhall@randvax.ARPA (Ed Hall) (01/07/84)
------------------------------------------------- >> It just goes to show, always type your code explicitly. >> Shun implicit declarations or type conversions -- they'll get you >> in the end. >> Steve Summit >> tektronix!tekmdp!stevesu A bit of a non sequitur here. Explicit casts have no effect on the bug. Even calling a double-to-long conversion function, where one exists, can't make op= behave (the syntax doesn' allow it). All you can do is avoid integer op= float altogether. The bug is an understandable one for a compiler writer. This is the only case where conversion operators can't easily be inserted before code generation. So, when floating-point is added to the compiler it is easy for this one to fall through the cracks. The small number of C programs that use floating-point are often written by people who aren't likely to use the more un-fortran-like deatures of C such as asignment ops. Thus, the bug itself goes relatively unnoticed. It should be noted that this bug affects /= and -= as well as *= operators. Whether += has problems depends upon whether the machine rounds or truncates. In the latter case it makes little difference whether truncation occurs before or after the addition. (Why is this not true for subtraction? --exercise for the reader.) -Ed Hall decvax!randvax!edhall
grunwald@uiuccsb.UUCP (01/13/84)
#R:decwrl:-475900:uiuccsb:9000010:000:55 uiuccsb!grunwald Jan 12 12:22:00 1984 What does the PCC compiler do with "integer *= float"?