Hello all,

Does the specification of minimum-width integer types (in <stdint.h>) assure the
expected integer rank hierarchy among them? For example in a hypothetical system
where there is no 32-bit wide type (nor any basic type having width in the range
[32, 63]) and both int and long are 64-bit wide, is it possible for a conforming
implementation to define int_least32_t as long and int_least64_t as int, thereby
implying that int_least32_t has a higher rank than int_least64_t?

Same question also applies for hierarchy among the fastest minimum-width types.
Continuing with the earlier example (and further assuming that both int and long
are equally fast), is it possible for a conforming implementation to define
int_fast32_t as long and int_fast64_t as int (inverting the expected hierarchy)?

Regards,
cHaR.

arnab chatterjee <arnabchatterjeeofficial@gmail.com> writes:

> Does the specification of minimum-width integer types (in
> <stdint.h>) assure the expected integer rank hierarchy among them?

No.

> For example in a hypothetical system where there is no 32-bit wide
> type (nor any basic type having width in the range [32, 63]) and
> both int and long are 64-bit wide, is it possible for a conforming
> implementation to define int_least32_t as long and int_least64_t as
> int, thereby implying that int_least32_t has a higher rank than
> int_least64_t?

Yes, assuming what you mean by "basic types" is the standard integer
types, and that this condition also applies to extended integer
types. All of the types in <stdint.h> are allowed to be extended
integer types.

> Same question also applies for hierarchy among the fastest
> minimum-width types. Continuing with the earlier example (and
> further assuming that both int and long are equally fast), is it
> possible for a conforming implementation to define int_fast32_t as
> long and int_fast64_t as int (inverting the expected hierarchy)?

Same answer as above.

On Wednesday, August 9, 2023 at 12:03:00 AM UTC-7, Tim Rentsch wrote:
> arnab chatterjee <arnabchatte...@gmail.com> writes:
>
> > Does the specification of minimum-width integer types (in
> > <stdint.h>) assure the expected integer rank hierarchy among them?
> No.
> > For example in a hypothetical system where there is no 32-bit wide
> > type (nor any basic type having width in the range [32, 63]) and
> > both int and long are 64-bit wide, is it possible for a conforming
> > implementation to define int_least32_t as long and int_least64_t as
> > int, thereby implying that int_least32_t has a higher rank than
> > int_least64_t?
> Yes, assuming what you mean by "basic types" is the standard integer
> types, and that this condition also applies to extended integer
> types. All of the types in <stdint.h> are allowed to be extended
> integer types.
> > Same question also applies for hierarchy among the fastest
> > minimum-width types. Continuing with the earlier example (and
> > further assuming that both int and long are equally fast), is it
> > possible for a conforming implementation to define int_fast32_t as
> > long and int_fast64_t as int (inverting the expected hierarchy)?
> Same answer as above.

Thank you for confirming this; it looks a little counter-intuitive to me, but I guess its quite unlikely to encounter any such implementation in practice.

On Wednesday, August 9, 2023 at 12:03:00 AM UTC-7, Tim Rentsch wrote:
> arnab chatterjee <arnabchatte...@gmail.com> writes:
>
> > Does the specification of minimum-width integer types (in
> > <stdint.h>) assure the expected integer rank hierarchy among them?
> No.
> > For example in a hypothetical system where there is no 32-bit wide
> > type (nor any basic type having width in the range [32, 63]) and
> > both int and long are 64-bit wide, is it possible for a conforming
> > implementation to define int_least32_t as long and int_least64_t as
> > int, thereby implying that int_least32_t has a higher rank than
> > int_least64_t?
> Yes, assuming what you mean by "basic types" is the standard integer
> types, and that this condition also applies to extended integer
> types. All of the types in <stdint.h> are allowed to be extended
> integer types.
> > Same question also applies for hierarchy among the fastest
> > minimum-width types. Continuing with the earlier example (and
> > further assuming that both int and long are equally fast), is it
> > possible for a conforming implementation to define int_fast32_t as
> > long and int_fast64_t as int (inverting the expected hierarchy)?
> Same answer as above.

Thank you for confirming this; it looks a little counter-intuitive to me, but I
guess its quite unlikely to encounter any such implementation in practice.

On 2023-08-09, arnab chatterjee <arnabchatterjeeofficial@gmail.com> wrote:
> On Wednesday, August 9, 2023 at 12:03:00 AM UTC-7, Tim Rentsch wrote:
>> arnab chatterjee <arnabchatte...@gmail.com> writes:
>>
>> > Does the specification of minimum-width integer types (in
>> > <stdint.h>) assure the expected integer rank hierarchy among them?
>> No.
>> > For example in a hypothetical system where there is no 32-bit wide
>> > type (nor any basic type having width in the range [32, 63]) and
>> > both int and long are 64-bit wide, is it possible for a conforming
>> > implementation to define int_least32_t as long and int_least64_t as
>> > int, thereby implying that int_least32_t has a higher rank than
>> > int_least64_t?
>> Yes, assuming what you mean by "basic types" is the standard integer
>> types, and that this condition also applies to extended integer
>> types. All of the types in <stdint.h> are allowed to be extended
>> integer types.
>> > Same question also applies for hierarchy among the fastest
>> > minimum-width types. Continuing with the earlier example (and
>> > further assuming that both int and long are equally fast), is it
>> > possible for a conforming implementation to define int_fast32_t as
>> > long and int_fast64_t as int (inverting the expected hierarchy)?
>> Same answer as above.
>
> Thank you for confirming this; it looks a little counter-intuitive to
> me, but I guess its quite unlikely to encounter any such
> implementation in practice.

It's not counter-intuitive; it's just that what you would find
intuitive is not imposed as a requirement. Implementors that care
about this can observe the ordering.

The least and fast types are chosen in programming situations in
which the exact size and identity of the type doesn't matter,
just that it holds at least a certain number of bits and is oriented
toward a particular time-space tradeoff.

Since the exact size of the type by itself doesn't matter, why would
its exact size or rank in comparison to another type matter.

That's the intuition: if the exact value doesn't matter in isolation, it
doesn't matter in comparison.

E.g. if you say that you believe that wealth doesn't matter, as long as
you're comfortably off, but then compare your wealth to richer people,
that is a contradiction, showing that your belief is not sincere.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Wednesday, August 9, 2023 at 8:18:15 AM UTC-7, Kaz Kylheku wrote:
> On 2023-08-09, arnab chatterjee <arnabchatte...@gmail.com> wrote:
> > On Wednesday, August 9, 2023 at 12:03:00 AM UTC-7, Tim Rentsch wrote:
> >> arnab chatterjee <arnabchatte...@gmail.com> writes:
> >>
> >> > Does the specification of minimum-width integer types (in
> >> > <stdint.h>) assure the expected integer rank hierarchy among them?
> >> No.
> >> > For example in a hypothetical system where there is no 32-bit wide
> >> > type (nor any basic type having width in the range [32, 63]) and
> >> > both int and long are 64-bit wide, is it possible for a conforming
> >> > implementation to define int_least32_t as long and int_least64_t as
> >> > int, thereby implying that int_least32_t has a higher rank than
> >> > int_least64_t?
> >> Yes, assuming what you mean by "basic types" is the standard integer
> >> types, and that this condition also applies to extended integer
> >> types. All of the types in <stdint.h> are allowed to be extended
> >> integer types.
> >> > Same question also applies for hierarchy among the fastest
> >> > minimum-width types. Continuing with the earlier example (and
> >> > further assuming that both int and long are equally fast), is it
> >> > possible for a conforming implementation to define int_fast32_t as
> >> > long and int_fast64_t as int (inverting the expected hierarchy)?
> >> Same answer as above.
> >
> > Thank you for confirming this; it looks a little counter-intuitive to
> > me, but I guess its quite unlikely to encounter any such
> > implementation in practice.
> It's not counter-intuitive; it's just that what you would find
> intuitive is not imposed as a requirement. Implementors that care
> about this can observe the ordering.
>
> The least and fast types are chosen in programming situations in
> which the exact size and identity of the type doesn't matter,
> just that it holds at least a certain number of bits and is oriented
> toward a particular time-space tradeoff.
>
> Since the exact size of the type by itself doesn't matter, why would
> its exact size or rank in comparison to another type matter.
>
> That's the intuition: if the exact value doesn't matter in isolation, it
> doesn't matter in comparison.
>
> E.g. if you say that you believe that wealth doesn't matter, as long as
> you're comfortably off, but then compare your wealth to richer people,
> that is a contradiction, showing that your belief is not sincere.
>
> --
> TXR Programming Language: http://nongnu.org/txr
> Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
> Mastodon: @Kazi...@mstdn.ca

Agreed, but it wouldn't harm if such a hierarchy were imposed as a requirement.
Width being an indicator of precision it makes sense that if a type is intended
to be at least as precise as another, then rank of the former should be higher
than that of the latter (aligned with the requirement for basic integer types).
It would look strange if operating on values of types int_least32_t and
int_least64_t gives the result with type int_least32_t.

On Wednesday, August 9, 2023 at 10:00:26 PM UTC-7, arnab chatterjee wrote:
> On Wednesday, August 9, 2023 at 8:18:15 AM UTC-7, Kaz Kylheku wrote:
> > On 2023-08-09, arnab chatterjee <arnabchatte...@gmail.com> wrote:
> > > On Wednesday, August 9, 2023 at 12:03:00 AM UTC-7, Tim Rentsch wrote:
> > >> arnab chatterjee <arnabchatte...@gmail.com> writes:
> > >>
> > >> > Does the specification of minimum-width integer types (in
> > >> > <stdint.h>) assure the expected integer rank hierarchy among them?
> > >> No.
> > >> > For example in a hypothetical system where there is no 32-bit wide
> > >> > type (nor any basic type having width in the range [32, 63]) and
> > >> > both int and long are 64-bit wide, is it possible for a conforming
> > >> > implementation to define int_least32_t as long and int_least64_t as
> > >> > int, thereby implying that int_least32_t has a higher rank than
> > >> > int_least64_t?
> > >> Yes, assuming what you mean by "basic types" is the standard integer
> > >> types, and that this condition also applies to extended integer
> > >> types. All of the types in <stdint.h> are allowed to be extended
> > >> integer types.
> > >> > Same question also applies for hierarchy among the fastest
> > >> > minimum-width types. Continuing with the earlier example (and
> > >> > further assuming that both int and long are equally fast), is it
> > >> > possible for a conforming implementation to define int_fast32_t as
> > >> > long and int_fast64_t as int (inverting the expected hierarchy)?
> > >> Same answer as above.
> > >
> > > Thank you for confirming this; it looks a little counter-intuitive to
> > > me, but I guess its quite unlikely to encounter any such
> > > implementation in practice.
> > It's not counter-intuitive; it's just that what you would find
> > intuitive is not imposed as a requirement. Implementors that care
> > about this can observe the ordering.
> >
> > The least and fast types are chosen in programming situations in
> > which the exact size and identity of the type doesn't matter,
> > just that it holds at least a certain number of bits and is oriented
> > toward a particular time-space tradeoff.
> >
> > Since the exact size of the type by itself doesn't matter, why would
> > its exact size or rank in comparison to another type matter.
> >
> > That's the intuition: if the exact value doesn't matter in isolation, it
> > doesn't matter in comparison.
> >
> > E.g. if you say that you believe that wealth doesn't matter, as long as
> > you're comfortably off, but then compare your wealth to richer people,
> > that is a contradiction, showing that your belief is not sincere.
> >
> > --
> > TXR Programming Language: http://nongnu.org/txr
> > Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
> > Mastodon: @Kazi...@mstdn.ca
> Agreed, but it wouldn't harm if such a hierarchy were imposed as a requirement.
> Width being an indicator of precision it makes sense that if a type is intended
> to be at least as precise as another, then rank of the former should be higher
> than that of the latter (aligned with the requirement for basic integer types).
> It would look strange if operating on values of types int_least32_t and
> int_least64_t gives the result with type int_least32_t.

"... then rank of the former should be higher than that of the latter ..."

Correction: The above line was meant to be

"... then rank of the former should not be lower than that of the latter ...."

arnab chatterjee <arnabchatterjeeofficial@gmail.com> writes:

[should types like intleastN_t have rules about their conversion
ranks?]

> Agreed, but it wouldn't harm if such a hierarchy were imposed as a
> requirement. [...]

There is no good reason to do it. The cost of adding such a
rule to the C standard is greater than zero, both initially
and in additional ongoing cost. Given that (a) it almost
never comes up, and (b) if/when it does it almost never
causes any material difference, the balance is in favor of
leaving things as they are and not putting in some rule that
offers negligible value and also easily can be taken care of
in those extremely rare situations where it (theoretically)
matters.