mitchell laks wrote:
Eduard Bloch <edi <at> gmx.de> writes:
I guess you mean int64_t and uint64_t (in contrary to int32_t/uint32_t,
etc.). And IMO one should use these types nowadays when the value range
is known upfront. Symbolic names are unreliable, int may be anything
larger than 16 bit and long may be anything larger 32 bit, but you can
This is incorrect. The Standard specifies what the representable
ranges are, not how many bits. Even if the underlying representation
only uses one bit for sign storage, the range for a short int does
not require more than 16 bits, nor does a long int require more than
32 bits. BTW, "long" is not a type, "long int" is a type. For example,
"long double" is also a type. Since the "default type" is "int"
(although no longer) "long" by itself is often thought of as being
a type.
never know for sure without testing.
There are macros defined for this.
I am very grateful to all of you for your information. This discusion is exactly
the information I sought in instigating this discussion.
I am curious how this was implemented for gcc 4.
Where do you recommend I can read more about the design decisions/issues for
programming using LP64 awareness for the Linux compiler collection gcc.
People have spoken to me off list about the need to avoid using compiler
specific extensions, thus not using anything not part of the C standard.
How does C standardization affect the issue of 32 vs 64 bit. I am familiar with
the "minimums" of char int and long . Are the int64_t things "standard" or only
"standard LP64" so to speak.
Where can I read tutorial/ other discussion information about these issues.
http://open-std.org/jtc1/sc22/wg14/www/docs/n869/n869.pdf.gz
http://www.ucalgary.ca/~bgwong/n869.pdf
Works for me. AIUI, the differences between the final draft
and the adopted Standard were slight language changes, but
no change in semantics. I also have a text version of that.
There are types which are the "minimum type" for a given size,
the "exact type" for a given size, and the "fastest type"
for a given size.
This excerpt might help you:
B.17 Integer types <stdint.h>
int8_t INT32_MIN UINT_FAST8_MAX
int16_t INT64_MIN UINT_FAST16_MAX
int32_t INT8_MAX UINT_FAST32_MAX
int64_t INT16_MAX UINT_FAST64_MAX
uint8_t INT32_MAX INTPTR_MIN
uint16_t INT64_MAX INTPTR_MAX
uint32_t UINT8_MAX UINTPTR_MAX
uint64_t UINT16_MAX INTMAX_MIN
int_least8_t UINT32_MAX INTMAX_MAX
int_least16_t UINT64_MAX UINTMAX_MAX
int_least32_t INT_LEAST8_MIN PTRDIFF_MIN
int_least64_t INT_LEAST16_MIN PTRDIFF_MAX
uint_least8_t INT_LEAST32_MIN SIG_ATOMIC_MIN
uint_least16_t INT_LEAST64_MIN SIG_ATOMIC_MAX
uint_least32_t INT_LEAST8_MAX SIZE_MAX
uint_least64_t INT_LEAST16_MAX WCHAR_MIN
int_fast8_t INT_LEAST32_MAX WCHAR_MAX
int_fast16_t INT_LEAST64_MAX WINT_MIN
int_fast32_t UINT_LEAST8_MAX WINT_MAX
int_fast64_t UINT_LEAST16_MAX INT8_C(value)
uint_fast8_t UINT_LEAST32_MAX INT16_C(value)
uint_fast16_t UINT_LEAST64_MAX INT32_C(value)
uint_fast32_t INT_FAST8_MIN INT64_C(value)
uint_fast64_t INT_FAST16_MIN UINT8_C(value)
intptr_t INT_FAST32_MIN UINT16_C(value)
uintptr_t INT_FAST64_MIN UINT32_C(value)
intmax_t INT_FAST8_MAX UINT64_C(value)
uintmax_t INT_FAST16_MAX INTMAX_C(value)
INT8_MIN INT_FAST32_MAX UINTMAX_C(value)
INT16_MIN INT_FAST64_MAX
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
