Path: utzoo!attcan!uunet!lll-winken!lll-ncis!helios.ee.lbl.gov!pasteur!ucbvax!ucsd!orion.cf.uci.edu!uci-ics!zardoz!dhw68k!arcturus!evil
From: evil@arcturus.UUCP (Wade Guthrie)
Newsgroups: comp.lang.c
Subject: Re: Subroutine layout in C
Summary: INT16 and INT32 have their place
Keywords: Here's a couple of handy macros...
Message-ID: <3346@arcturus>
Date: 9 Jan 89 16:49:27 GMT
References: <2459@ssc-vax.UUCP> <1987@lznh.UUCP> <18789@agate.BERKELEY.EDU>
Organization: Rockwell International, Anaheim, CA
Lines: 34

In article <18789@agate.BERKELEY.EDU>, bowles@eris.berkeley.edu (Jeff A. Bowles) writes:
> I worked for a very short time for a creepy compiler company that had
> several hundred thousand lines of this sort of crap.
> 
> 	PRIVATE  -> static
> 	PUBLIC	-> ""
> 	INT16	-> short int
> 	INT32	-> long int

In general I agree that typedefs and macros should be used judiciously
in order to help make things readable to the ordinary C programmer (if
you can call *any* C programmer ordinary :-> ).  However, I have seen
the use for INT16 and INT32 -- portability where the precision is
absolutely important.

For example: you want to partition a circle into little angles, and you
want to flag an occurrence of something if it exists in each angle.  The
way I chose to implement this was to partition my circle into 32 sections
(the number of bytes in the long or int on my machine -- to take advantage
of the speed improvements on some operations, I chose to use int) and do 
bitwise operations to set and check flags represented by the bits in 
that int.  Now, I need to port this to a machine that has 16 bit ints --
portability falls on its face.  This can be circumvented by using INT32 
where the size is important (and using short, int, and long where it is
not so critical).
 

Wade Guthrie
evil@arcturus.UUCP
Rockwell International
Anaheim, CA

(Rockwell doesn't necessarily believe / stand by what I'm saying; how could
they when *I* don't even know what I'm talking about???)