arwall@mit-amt (Anders Wallgren) (01/31/89)
I have noticed a few irritating things about the lint-like aspects of the MPW 3.0 C compiler...I would appreciate it if some more enlightened person could clue me in as to how I might fix/avoid or just plain live with the following problems: 1. When I compile with the -r and -w2 flags, the compiler complains everytime I assign a Boolean value. The <types.h> header defines the following: enum {false, true} typedef unsigned char Boolean; Typical code fragment: Boolean myBool; myBool = false; Result when compiled with C -r -w2: Warning #276: This assignment will loose some significant bits. What I suspect happens is that the compiler treats the enumerated type as a short or even a long. The 2.0.2 compiler could be frobbed to treat enumerated types as longs with the -z127 flag, but I didn't know that this was now standard practice...is there a fix for this? 2. Functions with variable numbers of arguments. I would appreciate a lucid example of how to write a function to take a variable number of (in my case) long arguments. Thanks! anders
emb90619@uxa.cso.uiuc.edu (02/01/89)
The problem with your Boolean assignment is the -w2 flag. This flag creates a condition where the compiler warns you of additional constructs which may be ok, but look fishy. enum types are ints (longs) in 3.0 ALWAYS. They are converted to short when sent to toolbox routines requiring shorts. To define a variable length argument, you use the elipsis (...) in the argument list. This must be three periods, you CANNOT use the mac option-; keystroke. So, void foo(...); is a prototype for a function foo, returning no value and having a variable length of arguments. Of course, no type checking will occur within the variable list, then. If you have some variables you want checked, you can put the elipsis later. For example, void foo(short a, long *b, ...); is a proper prototype.