Xref: utzoo comp.lang.c++:13219 comp.lang.c:38964
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!stanford.edu!shap@shasta.Stanford.EDU
From: shap@shasta.Stanford.EDU (shap)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: 64 bit architectures and C/C++
Message-ID: <178@shasta.Stanford.EDU>
Date: 3 May 91 03:06:26 GMT
References: <168@shasta.Stanford.EDU> <13229@goofy.Apple.COM>
Organization: Stanford University Computer Systems Laboratory
Lines: 33

In article <13229@goofy.Apple.COM> turk@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?