On Wed, Mar 29, 2023, 17:10 Frederick Virchanza Gotham via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Wed, Mar 29, 2023 at 3:29 PM Peter Olsson via Std-Proposals
<std-proposals@lists.isocpp.org> 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.

Not necessarily.  As long as you don't write any functions that accept it, or don't use structures that use it, it's fine to use it.  Instead of functions, use type-generic macros (or templates in C++), and you should be fine.

Proof of concept (in C):

<https://manpages.debian.org/testing/manpages-dev/_Generic.3.en.html>