🚀 go-pugleaf

In article <1990Dec12.141719.15833@mlb.semi.harris.com> routh@eltanin.rtp.semi.harris.com (Kevin Routh x622) writes:
>I own a Microsoft C version 5.0 and Quick C version 2.0.  I have been 
>wondering, is there a documented list of bugs for these vintage compilers?

    I've used MS C 5.0 extensively, and these are some of the bugs I've
noticed.  (I'm aware that some of these may be features, rather than bugs.
Some people have different opinions about how things should work.)
    1. It is impossible to send a '\032' character to a device, even if
it was open'ed in 'O_BINARY' mode.  This made it hard to send raw data
to my printer, or to redirect raw data from printer to disk, & vice
versa.
    2. It doesn't entirely support ansi standards, specifically with
regard to 'float' vs. 'double'.  I gave up entirely on using 'float'
variables at all.  (I know lots of 'C' gurus will flame me for wanting
to use single-precision floating point at all.)  There is no way to
construct a constant of type 'float'.
    3. If you have a coprocessor, and you tell the compiler to generate
code which works *only* with a coprocessor present, it works fine.  How-
ever, I think it does it in a strange way which I don't care for (it
generates self-modifying code.)
    4. If you have a coprocessor, the debugger ('CodeView') completely
fails to work with floating point instructions, despite the fact that
the documentation claims to support a coprocessor.  Something like:
    double a;
    a = 2.0 + 3.0;
    printf("a = %lf", a);
generally produces "a = 0.0" when run under CodeView.  (If you try
this simplre example, beware the optimizer!  It's hard to convince it
not to optimize out the floating-point addition at compile time.)
    5. The documentation claims it supports 'struct'ures as function
arguments and return values, with no limitations.  This is not true,
as when they expressions get complicated, the compiler generates
incorrect code.  I discovered this when converting real number routines
to complex numbers.  As long as the nesting was minimal, things worked
OK.  For example:
    typedef struct { double real, imag; } Complex;
    Complex Cadd(Complex, Complex);
    Complex Cmul(Complex, Complex);
    Complex a, b, c, d, e, f;
    /* a = ( (b+c)*d + e*f ); */
    a = Cadd( Cmul(Cadd(b,c), d), Cmul(e,f) );
compiles fine, but doesn't produce the correct value for 'a' at run time.
By contrast:
    /* same declarations as above */
    Complex temp1, temp2, temp3;
    /* a = ( (b+c)*d + e*f ); */
    temp1 = Cadd(b,c);
    temp2 = Cmul(temp1, d);
    temp3 = Cmul(e, f);
    a = Cadd(temp2, temp3);
always generates the correct value for 'a'.  (I hope this example makes
it clear--no guarantees it is typo-free.)
    6. *Most serious*.  MS' version of 'make' is stupid and nearly
useless.  No make file can be more than ~1400 bytes; dependency lists
must be short; it's stupid about update times.  The only way to use
make to maintain a library, for instance, is to have a seperate makefile
for each element in the library!  If you are ever going to use MS C 5.0
to do a medium-to-large project, it's worth buying someone else's make.
    7. Type checking is fairly primitive if you don't enable ANSI-type
function prototypes and the maximum level of warning messages (i.e. the
lowest threshold.)  I eventually gave up K&R style, and went to ANSI-style
function declarations, with the -W3 compile flag.  Since then, I've been
happy with it.
    I have pretty much only used it for small (albeit very computation
intensive programs) so I have little experience with large memory models,
&c.
    Please note that in other respects, the MS C 5.0 is an excellent
compiler.  It optimizes pretty well, compiles quickly, and almost always
generates correct code.  I've known compilers that did worse, and I
still use, after all these complaints.
-- 
Steve Brown                   sbbrown@magnus.ircc.ohio-state.edu