64 bit architectures and C/C++

shap shap at shasta.Stanford.EDU
Fri May 3 13:06:26 AEST 1991


In article <13229 at goofy.Apple.COM> turk at Apple.COM (Ken "Turk" Turkowski) writes:
>I would suggest:
>
>short	16 bits
>long	32 bits
>long long	64 bits
>int	UNSPECIFIED
>void *	UNSPECIFIED
>
>This is patterned after ANSI floating-point extensions to accommodate
>an extended format (i.e. "long double").
>
>Another proposal would be to invent a new word, like "big", "large",
>"whopper", "humongous", "giant", "extra", "super", "grand", "huge",
>"jumbo", "broad", "vast", "wide", "fat", "hefty", etc.
>
>Whatever chaice is made, there should be ready extensions to 128 and 256
>bit integers, as well as 128 and 256-bit floating point numbers.

Actually, that's what you did.  The 'long long' data type does not
conform to the ANSI standard.

The advantage to the approach
	short		16
	int		32
	long		32
	long long	64

Is that fewer datatypes change size (this approach leaves only
pointers changing), and the code could conceivably have the same
integer sizes in 32- and 64-bit mode.

But isn't ANSI conformance a requirement?



More information about the Comp.lang.c mailing list