Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!uw-beaver!apollo!hays
From: hays@apollo.UUCP
Newsgroups: comp.emacs,comp.sys.atari.st
Subject: Re: uEmacs38b Fixes for ATARI ST
Message-ID: <3423153f.9540@apollo.uucp>
Date: Tue, 7-Apr-87 17:46:00 EST
Article-I.D.: apollo.3423153f.9540
Posted: Tue Apr  7 17:46:00 1987
Date-Received: Sat, 11-Apr-87 03:28:09 EST
References: <48200001@tub.UUCP> <273@xios.XIOS.UUCP> <611@batcomputer.tn.cornell.edu>
Reply-To: hays@apollo.UUCP (John Hays)
Organization: Apollo Computer, Chelmsford, MA
Lines: 33
Xref: utgpu comp.emacs:756 comp.sys.atari.st:2588

In article <611@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu.UUCP (braner) writes:
>[]
>
>(C experts hit 'j' now!)
>
>It is a general problem with porting C programs that some C programmers
>assume that a 'short' is 16 bits or that an 'int' is 32 bits or that a

>C code to simplify porting later!  At least, use WORD when you access
>OS data-structures that are 16-bits wide, and use LONG when you need
>more than 16 bits.
>

I like the following approach better as it is more discriptive:

#define int32 int /* or your 32-bit integer */
#define int16 short /* or your 16-bit integer */
                    /* etc */

If this is put in a header file used by all of your code then
you make the change once.

.....

John

.....

-- 
John D. Hays, Consultant             UUCP: ...!decvax!wanginst!apollo!hays  
Corporate Systems Engineering              ...!uw-beaver!apollo!hays
Apollo Computer Inc.                 CIS: 72725,424  {weekly} 
               !MY OPINIONS, not Apollo's!