Rich,

on Wed, 31 May 2023 10:57:24 -0400 you (Rich Felker <dalias@libc.org>)
wrote:

> On Wed, May 31, 2023 at 04:55:45PM +0200, Jₑₙₛ Gustedt wrote:
> > Rich,
> > 
> > on Wed, 31 May 2023 10:41:29 -0400 you (Rich Felker
> > <dalias@libc.org>) wrote:
> >   
> > > On Wed, May 31, 2023 at 04:36:43PM +0200, Jₑₙₛ Gustedt wrote:  
>  [...]  
>  [...]  
>  [...]  
> > > 
> > > Can you cite that?  
> > 
> > sure, almost by heart, since I wrote that ;-)
> > 
> >   … with the possible exceptions of signed bit-precise integer types
> >   and of signed extended integer types that are wider than `long
> > long` and that are referred by the type definition for an exact
> > width integer type
> >   
> > > Because I don't see it. I still see that intmax_t
> > > has to be at least as wide as all the intN_t.  
> > 
> > I seems that you read that the wrong way around.  
> 
> OK, so AIUI based on this exception it's permitted but not required to
> offer int128_t.

yes

But compilers can never offer it if there is not minimal C library
support, which we are doing here. This is the only way we found in
yearlong discussions in WG14 to get us out of this intmax_t ABI trap.

For the 128 bit types in particular this answers numerous requests by
users who want to have these in different contexts and where quite
frustrated that compilers have these since decades but where not able
to announce them officially, not even as extended integer types.

Thanks
Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::