routh@eltanin.rtp.semi.harris.com (Kevin Routh x622) (12/12/90)
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 can't really afford the $$$ to upgrade them, and I wonder if there are
problems which are intolerable. I think that the libraries were upgraded
when I installed the Quick C. Can someone help me? Thanks a lot.
--
Kevin Routh (routh@rtp.semi.harris.com)
Harris Corporation, Durham, NC
(919) 361-1622
--
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.sbbrown@magnus.ircc.ohio-state.edu (Stephen B. Brown) (12/14/90)
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
otto@tukki.jyu.fi (Otto J. Makela) (12/14/90)
In article <1990Dec13.165542.21022@magnus.ircc.ohio-state.edu> sbbrown@magnus.ircc.ohio-state.edu (Stephen B. Brown) writes:
[MicroS*t C 5.0 bugs]
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. [...]
I believe this is caused by MS-DOS, not MS C 5.0 --
One of the peculiarities of MeSsy-DOS is that file handles have a primitive
binary/text mode. The only thing that the binary mode does is when writing
to a device it is impossible to write a ^Z (0x1A, 032) character. Guess in
which mode the device files (PRN, AUX etc.) are as default ?
You need to do a IOCTL to change the file handle to binary mode and all will
work correctly. However, I think that a C stdio library should be smart
enough to do this on it's own if the file was opened with O_BINARY (or "wb",
if you are using the buffered I/O functions).
--
/* * * Otto J. Makela <otto@jyu.fi> * * * * * * * * * * * * * * * * * * */
/* Phone: +358 41 613 847, BBS: +358 41 211 562 (CCITT, Bell 24/12/300) */
/* Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland, EUROPE */
/* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * * * * * */