On Wed, Mar 29, 2023, 17:10 Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> 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.
>

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>

-- 
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>