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