64 bit architectures and C/C++

Phil Howard KA9WGN phil at ux1.cso.uiuc.edu
Sat May 11 06:46:25 AEST 1991


det at nightowl.MN.ORG (Derek E. Terveer) writes:

>What is wrong with simply implementing the following in a compiler?

>	char	=	 8 bits
>	short	=	16 bits
>	int	=	32 bits
>	long	=	64 bits

There is apparently (as some people complain about) code out there that
depends upon the MAX size of the type.  In other words, if "long" is
longer than 32 bits, it breaks.

But porting such code to a 64-bit machine *AND* writing good standardized
code for the same machine are in mutual conflict because of this.

The only way out I can see is for the compiler to default to what is the
most reasonable for NEW AND GOOD code to be developed, and have some sort
of flag or flags to allow it to be customized to better handle the cases
of porting old code.  I'd also suspect that if you can find code where the
long depends on being exactly 32 bits, you could well find code where the
int depends on being exactly 16 bits.  So there probably is not one single
ideal solution to the problem.  So perhaps a system of flags like:

  -SHORTnn
  -INTnn
  -LONGnn

Which actually change the sizes of the primitive types, giving a warning
if the "short <= int <= long" constraint is violated (but do the compile
as specified anyway).

It would be an extension, not standard C.  But when porting old code, we
aren't addressing standards, are we?
-- 
 /***************************************************************************\
/ Phil Howard -- KA9WGN -- phil at ux1.cso.uiuc.edu   |  Guns don't aim guns at  \
\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/



More information about the Comp.lang.c mailing list