Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!ames!ucbcad!ucbvax!decvax!tektronix!cae780!ubvax!weitek!neal
From: neal@weitek.UUCP (Neal Bedard)
Newsgroups: comp.lang.c
Subject: Re: Standard int sizes
Message-ID: <421@jetsun.weitek.UUCP>
Date: Thu, 9-Apr-87 01:24:38 EST
Article-I.D.: jetsun.421
Posted: Thu Apr  9 01:24:38 1987
Date-Received: Mon, 13-Apr-87 06:03:57 EST
References: <6759@brl-adm.ARPA>
Reply-To: neal@jetsun.UUCP (Neal Bedard)
Organization: Weitek Corporation, Sunnyvale
Lines: 40

In article <6759@brl-adm.ARPA> dsill@NSWC-OAS.arpa writes:
>kyle@xanth.cs.odu.edu (kyle jones) wrote:
>>I would like to see the sizes of C integral types standardized.
>>One proposal might be:
>>
>>	char	 8 bits
>>	short	16 bits
>>	int	32 bits
>>	long	64 bits
>
>I'd rather have:
>	short    8 bits
>	int	16 bits
>	long	32 bits
>and something like "xlong" for 64 bits.

K&R states that "int" typically indicates the "natural" size of the machine,
i.e., whatever the "integer datapath size" is. This is typically easiest entity
to generate addresses for - so "int" should probably stay as it is. However, it
would be nice to eliminate the ambiguity in the other sizes.

*My* half-baked size proposal would be:

	char		8 bits
	short		16 bits
	long		32 bits	= float
	octaword	64 bits = double
	hexaword	128 bits = extend (extended floating-point formats)

This setup would accommodate pretty much everybody whose "char" size is 8 bits.
I have no quarrel over the actual names really, as long as they're distinct
from each other and mean the same thing from compiler to compiler - which is
what everyone wants, no?

Now, *my* question is, what do you do for machines that address things that
aren't 2**n bits wide? This is is where the *real* fun begins...



-Neal