andrew@alberta.UUCP (Andrew Folkins) (05/22/85)
*** REPLACE THIS LINE WITH A C COMPILER *** I'm looking for a C compiler for an XT. I know this has been mentioned in the past, could someone with the results please mail them to me? (Any other opinions would also be welcome.) Thanks in advance. -- Andrew Folkins ihnp4!alberta!andrew
cramer@kontron.UUCP (Clayton Cramer) (05/31/85)
> > I'm looking for a C compiler for an XT. I know this has been mentioned > in the past, could someone with the results please mail them to me? > (Any other opinions would also be welcome.) > > Andrew Folkins > ihnp4!alberta!andrew I can heartily recommend the Microsoft C Compiler V3.0. (This is NOT the Lattice C compiler sold under Microsoft's name.) I have found only one bug so far, and that is a pretty trivial one --- if I neglect to give the extension on the file name when using the CL command, it doesn't seem to figure out that there is no file by that name, but it goes ahead and tries to do a link anyway. We are using it to port a medium sized application written in VAX C to an AT; the only problems we have had with the port are bad programming practices in our code. I will be posting a list of suggestions for ways to avoid trouble doing this port in the next few days to net.micro.pc.
brent@cadovax.UUCP (Brent Rector) (06/12/85)
>I can heartily recommend the Microsoft C Compiler V3.0. (This is NOT the >Lattice C compiler sold under Microsoft's name.) I have found only one >bug so far, and that is a pretty trivial one --- if I neglect to give >the extension on the file name when using the CL command, it doesn't seem >to figure out that there is no file by that name, but it goes ahead and >tries to do a link anyway. While I agree that the new Microsoft C Compiler V3.0 is better than the Lattice C compiler V2.14, I have found one bug that is a real pain to locate. If you define a global variable with the same name as a library function BAD CODE is generated and extremely unpredictable results occurs. E.g. int eof; main() { printf("Hello world\n"); } func() { eof = 1; } Causes the library eof() routine to be loaded and all references to the integer global variable eof are relative to the data segment as expected; but to the offset of the eof() routine in the code segment! The integer eof is not even allocated as far as I can tell. Initializing the variable (int eof=0;) corrects the problem; as does renaming it. So watch out if your variables match library routines. In my particular case I wasn't even using the eof() function. I called Microsoft but they couldn't give me any date on when their next release would be available. Also they said that typically they do not issue patches for any but critical problems. This may not be as serious as some problems they may or may not have but locating this kind of bug certainly will try some peoples patience. I recommend that you initialize ALL global variables if they have a remote chance of matching a library routine name. Wouldn't you know it, this bug was in the first program I tried to use with the new compiler! All others have worked great though and if you are trying to port a C program originally written for UNIX, Microsofts C compiler V3.0 is the way to go! -------------------------------------------------------------- Brent E. Rector - CONTEL CADO, Torrance, CA { decvax, hplabs, ihnp4, ucbvax, sdcrdcf }!trwrb!cadovax!brent philabs!cadovax!brent