[Guido]
> ... (Is a summary of these [C9X] names online somewhere?)
ISO refuses to put current stds online, so I'll reword an anonymous source
(shhh! & some of this may be a little out of date):
Exact-width typedefs:
int8_t int16_t int32_t int64_t
uint8_t uint16_t uint32_t uint64_t
It's allowed that a given platform not define *any* of these.
Therefore portable code can never rely on having exactly N bits
regardless of N.
Minimum-width typedefs:
int_least8_t int_least16_t int_least32_t int_least64_t
uint_least8_t uint_least16_t uint_least32_t uint_least64_t
*All* of these must be defined (so even teensy platforms have to
fake at least 64 bits).
Fastest minimum-width typedefs:
int_fast8_t int_fast16_t int_fast32_t int_fast64_t
uint_fast8_t uint_fast16_t uint_fast32_t uint_fast64_t
All of these must exist. What's the difference between these and
minimum-width? For example, on a Cray J90 the least8_t will be a
char, but since the HW supports no byte operations, the fast8_t will
likely be 64 bits wide.
Pointer<->int casting
intptr_t
uintptr_t
These are signed & unsigned int types such that a valid void* p can
be cast to them and back again, yielding a result == p. Very
curiously, the last draft std I saw allowed for neither to be defined!
Fattest types
intmax_t
uintmax_t
The biggest int type (note that this may be fatter than "long long"!).
Must be defined.
Limit macros
The names of these match the regexp (re.VERBOSE):
U? INT (8|16|32|64) _ (MIN|MAX)
| U? INT_ (LEAST|FAST) (8|16|32|64) _ (MIN|MAX)
| INTPTR_ (MIN|MAX)
| UINTPTR_MAX
| INTMAX_ (MIN|MAX)
| UINTMAX_MAX
Macros for literals
The names match the regexp:
U? INT (8|16|32|64) _C
Each of these 8 macros takes an integer literal argument, and
expands it to whatever gibberish the platform needs to make a
valid literal of at least the specified width.
Also INTMAX_C(lit) and UINTMAX_C(lit), to do likewise for the
fattest type (intmax_t or uintmax_t) supported by the platform.
Macros for format specifiers
There are many dozens of these! They address the problem that it's
great you can now ask for, e.g., an int_fast32_t, but you still have
no idea how big it is so also no idea what to stick in printf or
scanf formats to do correct I/O on values of that type.
Other limits
ptrdiff_t: PTRDIFF_MIN PTRDIFF_MAX
sig_atomic_t: SIG_ATOMIC_MIN SIG_ATOMIC_MAX
size_t: SIZE_MAX
wchar_t: WCHAR_MIN WCHAR_MAX
wint_t: WINT_MIN WINT_MAX
I don't expect Python needs more than half a dozen of these, but haven't
given it sufficient thought. If somebody else beats me to it, I would be
pleased <wink>.
the-very-need-for-names-like-intmax_max-is-a-strong-argument-
for-euthanasia-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4