Xref: utzoo comp.lang.c++:13196 comp.lang.c:38924
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!uwvax!heurikon!ex.heurikon.com!daves
From: daves@ex.heurikon.com (Dave Scidmore)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: 64 bit architectures and C/C++
Message-ID: <470@heurikon.heurikon.com>
Date: 1 May 91 21:02:27 GMT
References: <168@shasta.Stanford.EDU> <6157@trantor.harris-atd.com>
Sender: news@heurikon.heurikon.com
Reply-To: daves@ex.heurikon.com (Dave Scidmore)
Organization: Heurikon Corporation, Madison, WI
Lines: 26

In article <6157@trantor.harris-atd.com> mvm@jedi.UUCP (Matt Mahoney) writes:
>When I need to specify bits, I'm usually forced to make the 
>following assumptions:
>
>	char	8 bits
>	short	16 bits
>	long	32 bits
>
>since this is true on most machines.  Anything else would probably break
>a lot of code.

I'm supprised nobody has mentioned that the real solution to this kind
of portability problem is for the original programmer to use the
definitions in "types.h" that tell you how big chars, shorts, ints,
and longs are. I know that a lot of existing code does not take advantage
of the ability to use typdefs or #defines to alter the size of key
variables or adjust for numbers of bits for each, but doing so would
help prevent the kinds of portability problems mentioned. I always urge
people when writing their own code to be aware of size dependent code
and either use the existing "types.h", or make their own and use it to
make such code more portable. This won't help you when porting someone
elses machine dependant (and dare I say poorly written) code, but the next
guy who has to port your code will have an easier time of it.
--
Dave Scidmore, Heurikon Corp.
dave.scidmore@heurikon.com