Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!ogicse!cvedc!gssc!timr
From: timr@gssc.UUCP (Tim Roberts)
Newsgroups: comp.lang.c
Subject: Re: 64 bit architectures and C/C++
Message-ID: <6659@gssc.UUCP>
Date: 22 May 91 17:59:41 GMT
References: <1991May6.232116.11401@sq.sq.com> <1991May9.192156.19291@nightowl.MN.ORG> <313@orac.UUCP>
Organization: Graphic Software Systems, Inc. Beaverton, Or.
Lines: 32

In article <313@orac.UUCP> bret@orac.UUCP (Bret Indrelee) writes:
>In article <1991May9.192156.19291@nightowl.MN.ORG> det@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
>
>I agree, this is the best of many choices.  

Wrong!  This is NOT necessarily the best of many choices.  THINK about this
for a minute!  We've had a lot of entirely useless philisophical discussion
on this issue.

What if your 64 bit architecture doesn't have any instructions to deal with
16 bit units?  You certainly aren't going to include something as a fundamental
type when your architecture can't easily deal with it, are you?  What if, going
further, you can't manipulate 32 bit objects either?  On such a machine, you
would probably create short=int=long=64 bits.

The point is this:  C data types are intended to map into the fundamental
operating units of the underlying hardware.  Discussing the correctness of
C data type sizing on 64-bit machines in the general case is a pointless waste 
of network bandwidth.

-- 
timr@gssc.gss.com	Tim N Roberts, CCP	Graphic Software Systems
						Beaverton, OR

This is a very long palindrome. .emordnilap gnol yrev a si sihT