I agree that it would be a very strange implementation to define
std::uint_fast32_t to be a type that has this issue. I am not aware of any that
do define std::uint_fast32_t this way. Also, char is not an unsigned integer
type so it can't be used as the type for std::uint_fast32_t (even if its
underlying type is unsigned char).

On Wed, Nov 6, 2024 at 3:28 AM Jonathan Wakely via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
>
>
> 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.
>
>
>
>
>>
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals