cramer@kontron.UUCP (Clayton Cramer) (07/02/85)
If you are an experienced C programmer, this posting may not be of much
interest to you --- everyone else may find our experiences here at Kontron
porting programs from the Berkeley 4.2 C compiler to Microsoft C V3.0
of interest.
First of all, Microsoft C V3.0 seems to be *very* solid --- we have yet to
find a serious error in it. The only minor error we have found is that
if you give the command:
cl progname
where progname doesn't have the filename extension, it will fail to
compile the program, but go ahead and try to link it anyway, without warning.
Perhaps this isn't really a bug, but it can be darned annoying.
What we *have* found about Microsoft C is that it is much more demanding of
valid C than the Berkeley 4.2 C compiler. For starters:
1. I declared a module level variable as extern in an include file;
unfortunately, I stupidly declared it:
extern int CurDispWindow ();
Where I attempted to reference this variable, I coded:
function (..., &CurDispWindow);
which the Berkeley 4.2 compiler accepted, linked, and executed correctly.
The function call generated a pointer to the int CurDispWindow, not a
pointer to the non-existent function CurDispWindow ().
Microsoft C V3.0 generated error messages while compiling the function
call. (I didn't notice the error messages at first --- I got to the
point of debugging the call before I noticed zeroes being pushed on the
stack instead of &CurDispWindow).
2. The types of long and int are the same size on the VAX; when you pass
an constant to a function which is expecting a long, this works on the
VAX, but not with Microsoft C V3.0, because long and int are different
sizes. The VAX compiler doesn't warn you about these mismatched types,
which can get you in some trouble, since the symptoms on the PC are
unobvious.
3. Similarly, if you neglect to declare a function extern that returns char*,
the 4.2 compiler executes the resulting program correctly, since char*
and int are the same size. On the PC this works in small model, because
char* and int are the same size. On the PC in large model, char* and
int are no longer the same size, and since undeclared functions are
assumed to be int, the char* returned gets chopped down to just the
offset. This is especially confusing because the program works in small
model, and suddenly stops working in large model.