Schauble@mit-multics.arpa (Paul Schauble) (03/23/87)
I've recently acquired Microsoft C version 4.0, replacing Lattice
version 2.15. In most aspects, it's a considerable improvement, and I
wouldn't give up Codeview for anything else I've seen. However, I just
had something happen that has badly soured me on the compiler. The
problem is this
Within one file I have the function declaration
void bgunlink_transaction_record (bgfile, client, transaction)
BGFILE *bgfile;
struct tclient_rec *client;
struct ttransaction_rec *transaction;
{
....
}
The type BGFILE and the structures are correctly declared prior to this.
Later in the file I have the statement
bgunlink_transaction_record (&bgfile, &client_rec, rec, &transaction);
Note that they don't match in number or types of arguments. When
compiling with /W3 for maximum checking, the compiler SAYS NOT A WORD
ABOUT THIS.
I realize that I didn't write a prototype for the function, but when
it's DECLARED IN THE SAME COMPILATION, I shouldn't have to. Lattice
managed to get this one right.
I guess there had to be a letdown from my initial enthusiasm for this
compiler. But, people, this one is so dumb it hurts.
regretfully,
Paul
heather@blia.UUCP (03/24/87)
In article <5397@brl-adm.ARPA>, Schauble@mit-multics.arpa (Paul Schauble) writes: > I've recently acquired Microsoft C version 4.0, replacing Lattice > > Within one file I have the function declaration > > void bgunlink_transaction_record (bgfile, client, transaction) > BGFILE *bgfile; > struct tclient_rec *client; > struct ttransaction_rec *transaction; > > Later in the file: > > bgunlink_transaction_record (&bgfile, &client_rec, rec, &transaction); > > Note that they don't match in number or types of arguments. When > compiling with /W3 for maximum checking, the compiler SAYS NOT A WORD > ABOUT THIS. On pages 77-79 of the Microsoft C Compiler User's Guide, the /Zg option is described. This is also the section that describes type checking on functions. In a box on the middle of page 78, there is a warning that /Zg will not work for structs, enums or unions (or pointers to such) unless the struct declaration includes a tag. My guess, based on other Microsoft "features", is that type checking follows this constraint also. I also like Codeview and Microsoft in general far better than Lattice. But there are many undocumented or poorly documented limitations that make it much more difficult to use than it should be. The support organization has never let me in on the secret the first time I call in about a problem; they always let me discover the limitations for myself. The biggest gripe I have is that Codeview cannot be used in source mode with files included in a library. Since we sell a source library product, this is a big pain for me. You can't even put a breakpoint at a routine which is in a library, no matter how much symbolic information is in the .obj file. I don't want to sour anybody on Microsoft. It is far better than the compilers available when I started on the PC in 1983. It is also the most complete professional C compiler for the PC I have seen. But the documentation seems to be marketing literature and can be very frustrating if you are trying to do real world programming. Heather Mackinnon PC Guru :-) Britton-Lee, Inc.
gary@darth.UUCP (03/25/87)
In article <5397@brl-adm.ARPA> Schauble@mit-multics.arpa (Paul Schauble) writes: >I've recently acquired Microsoft C version 4.0, replacing Lattice >version 2.15. In most aspects, it's a considerable improvement, and I >wouldn't give up Codeview for anything else I've seen. However, I just >had something happen that has badly soured me on the compiler. The >problem is this > >Within one file I have the function declaration > > void bgunlink_transaction_record (bgfile, client, transaction) > BGFILE *bgfile; > struct tclient_rec *client; > struct ttransaction_rec *transaction; > { > .... > } > >The type BGFILE and the structures are correctly declared prior to this. >Later in the file I have the statement > > bgunlink_transaction_record (&bgfile, &client_rec, rec, &transaction); > >Note that they don't match in number or types of arguments. When >compiling with /W3 for maximum checking, the compiler SAYS NOT A WORD >ABOUT THIS. >[...] It is not always desirable to have the compiler assume that a previously declared function is prototyped. For example: void wishy_washy_func(code, optional_arg); If the second argument in this function is optional (that is, present for some values of "code" and absent for others), the following are perfectly acceptable: wishy_washy_func(OPTION_A); wishy_washy_func(OPTION_B, i); So long as there is logical consistency, no problems occur. Of course, this is a contrived example, and there is no way for the compiler to typecheck uses. I don't particularly advocate such constructions, but wonder whether such considerations were in mind when Microsoft implemented their compiler. With Lattice, the above is still possible if a prototype such as: wishy_washy_func(enum ww_option, ...); is defined. This is probably better, since optional arguments are rarer and often compromise portability. I would be curious if anyone else can post a case where default prototyping is undesirable. Gary J. Wisniewski uucp: {allegra, bellcore, cadre}!pitt!darth!gary "Searching for truth is more rewarding than finding it."