From: Keith.S.Thompson+u@gmail.com

bart  writes:
> On 24/11/2025 20:26, David Brown wrote:
[...]
>> And this huge leap also lets you have 128-bit, 256-bit, 512-bit,
>> etc.,
>
> And 821 bits. This is what I don't get. Why is THAT so important?
>
> Why couldn't 128/256/etc have been added first, and then those funny
> ones if the demand was still there?

Because a more general definition, allowing all widths up to some
maximum, is *simpler* than a definition with arbitrary restrictions.
And since it's already been implemented, what the heck are you
complaining about?

> If the proposal had instead been simply to extend the 'u8 u16 u32 u64'
> set of types by a few more entries on the right, say 'u128 u256 u512',
> would anyone have been clamouring for types like 'u1187'? I doubt it.

You do know that u8, u16, et al are not C types, right?  (Yes, I know
what you mean by those names.)

> For sub-64-bit types on conventional hardware, I simply can't see the
> point, not if they are rounded up anyway. Either have a full
> range-based types like Ada, or not at all.

Great, so don't use them.

If the ISO C committee withdrew the current official 2023 standard
document and replaced it with one that imposes restrictions on _BitInt
types, and gcc and clang withdrew their implementations, would that
satisfy you?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)