On 29/03/2023 17:09, Frederick Virchanza Gotham via Std-Proposals wrote:
> On Wed, Mar 29, 2023 at 3:29 PM Peter Olsson via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>
>>> The standard already defines - as you suggested - two categories:
>>> standard integer types and extended integer types.
>>> It could really make sense to introduce - as you called it -
>>> `uintmax_oversize_t` -, or better named `uintmax_extended_t` to
>>> cover both stand and extended types.
>>
>> Wouldn't uintmax_extended_t introduce the same problem again when
>> vendors wants to add new bigger extended integer types in the future?
>
>
> You beat me to it.
>
> Right now the biggest is uint128_t, but I'm gonna fork the GNU gcc
> repository on Github and make a uint256_t type. So then any code that
> previously used uintmax_overall_t won't be ABI-compatible with a new
> program compiled today with the 256-Bit compiler.

That seems like a lot of effort for a single use-case. It is true that
in cryptography, big integers are useful - but you need a lot of
different sizes. A 256-bit integer will be of no benefit to SHA-224,
SHA-384, SHA-512, or any other cryptography algorithm that needs
different sizes or bigger sizes. Even for SHA-256, it will be of no
particular use for serious implementations, since these are often
fine-tuned for different processor SIMD features, and all the
calculations for SHA-256 are done using 32-bit parts.