Beej Jorgensen wrote:
> James Kuyper <(EMail Removed)> wrote:
>> On any implementation where uintmax_t is suitable for such use,
>> uintptr_t is likely (guaranteed?) to supported, so there's no point in
>> worrying about uintmax_t.
>
> uintptr_t is optional, but if it exists, the required uintmax_t can
> represent it. That's my read on the Standard, anyway (C99 7.18.1.45).
>
> I'd agree with "likely", though.
I'm looking at this from the opposite direction. If uintmax_t can do the
job, then it is a type suitable for definition as uintptr_t. There might
be a more suitable type (smaller, faster), but you know that there's at
least one that is suitable. It would be perverse to have a suitable
type, and not make it available as uintptr_t; but the standard does not
prohibit such perversions.
This should be contrasted with the exactwidth types, where if an
implementation supports a type that meets the requirements for
[u]int8_t, [u]int16_t, [u]int32_t, or [u]int64_t, it must define the
corresponding typedefs.
