[comp.sys.mac.programmer] MPW 3.0: Booleans and var #of args.

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.