Date: Wed, 29 Mar 2023 16:09:56 +0100
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.
<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.
Received on 2023-03-29 15:10:08