On Wed, 6 Nov 2024, 08:14 Giuseppe D'Angelo via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> Il 06/11/24 08:52, Halalaluyafail3 via Std-Proposals ha scritto:
> > I'm thinking about making a LWG issue for this, though it seems like it
> is
> > preferred to post to this mailing list first.
>
> I think this is another case of this issue:
>
> https://cplusplus.github.io/LWG/issue4109
>
> The issue raises a genuine concern: int8_t may be an alias for char, and
> thus giving UB (because char is not in the list).
> But your case sounds way more theoretical. Is there a real-world
> implementation where uint_fast32_t isn't one of the listed types?
>

It would need to be a platform with 32-bit char, or a platform where for
some reason an extended integer type (e.g. 128-bit or 256-bit integers) are
faster than smaller ones (e.g. 32-bit ones, where supported).

In the former case, using char or unsigned char for uint_fast32_t would be
a terrible choice, for all the same reasons that uint8_t is problematic on
widespread platforms today. It would be a very user hostile implementation
(and there's a proposal to mandate that CHAR_BIT == 8 which would make such
a platform non-conforming anyway).

In the latter case, there seems no reason to pick an extended integer type
over one of the standard integer types that are required to support more
than 32 bits. That would also be user hostile.

My preferred resolution for lwg 4109 would be something like
conditionally-supported, so either it's well-defined and works or it's ill
-formed. No UB.

That would address this hypothetical problem too.

I can add a note to 4019 about this case, I don't think we need a separate
issue.





>
>