Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!zrm
From: zrm@mit-eddie.UUCP
Newsgroups: comp.sys.mac
Subject: Re: MPW C annoyances....
Message-ID: <5309@mit-eddie.MIT.EDU>
Date: Tue, 31-Mar-87 09:03:15 EST
Article-I.D.: mit-eddi.5309
Posted: Tue Mar 31 09:03:15 1987
Date-Received: Thu, 2-Apr-87 01:13:39 EST
References: <12500007@acf4.UUCP> <2926@sdcsvax.UCSD.EDU>
Reply-To: zrm@eddie.MIT.EDU (Zigurd R. Mednieks)
Organization: MIT, EE/CS Computer Facilities, Cambridge, MA
Lines: 34

In article <2926@sdcsvax.UCSD.EDU> jww@sdcsvax.UCSD.EDU (Joel West) writes:
>
>Every Macintosh C programmer should start his code with
>
>	typedef Byte char;
>	typedef Half short;
>	typedef Full long;
>
>(or pick other names you like better) and expect int to be either size.
>The only case I can think of to use int is if you always pass an
>integer constant as an argument and are too lazy to coerce it 
>each time (which can be easily solved by a macro, btw).

Creating datatypes that are guaranteed to be a certain size does make
a lot of sense for code that has to be very portable, e.g. b*-tree
libraries and other highly system and processor independent code. Most
Macintosh code, though, is going nowhere other than a Macintosh. In
light of that fact, it would have been nice if Apple had specified its
Apple-label  C compiler to conform more closely to its Pascal compiler
datatypes. That would have, by the way, obviated the need to coerce
types in arguments to Toolbox calls, which is not really standard C.

The style of C programming suggested by Joel is laid out in great
detail in a Plum Hall book on C programming. In most cases I think
that style is too rigid and makes for code which is hard to read,
partly because it is difficult to tell the difference between defined
types that are aggregates (e.g. structures) and those that are not,
without always checking the header files.

By minimizing the number of alterations made to bare-bones C, you
minimize the number of things a new maintainer must learn before he
can begin improving or porting the code.

-Zigurd