[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 31 May 2023 11:40:43 -0400
From: Rich Felker <dalias@...c.org>
To: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
Cc: musl@...ts.openwall.com
Subject: Re: [C23 128 bit 4/4] C23: implement proper support for
int128_t and uint128_t
On Wed, May 31, 2023 at 05:37:18PM +0200, Jₑₙₛ Gustedt wrote:
> Rich,
>
> on Wed, 31 May 2023 11:14:06 -0400 you (Rich Felker <dalias@...c.org>)
> wrote:
>
> > On Wed, May 31, 2023 at 05:07:00PM +0200, Jₑₙₛ Gustedt wrote:
> > > Rich,
> > >
> > > on Wed, 31 May 2023 10:57:24 -0400 you (Rich Felker
> > > <dalias@...c.org>) wrote:
> > >
> > > > On Wed, May 31, 2023 at 04:55:45PM +0200, Jₑₙₛ Gustedt wrote:
> > [...]
> > [...]
> > > > [...]
> > > > [...]
> > > > [...]
> > [...]
> > [...]
> > [...]
> > [...]
> > > >
> > > > 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.
> >
> > OK, well this whole thread/topic then is a request/proposal for
> > extended functionality, not part of C23 support, and needs to be
> > considered as such.
>
> That's a stretch. It is an optional feature, we implement other
> optional features. This a feature that the C standard describes and
> that we are able to provide with relatively low effort.
>
> > I'm sorry there seems to have been a misunderstanding here. I'm trying
> > to understand where you're coming from, and I think now you were
> > probably looking at the intmax_t situation as if int128_t was
> > something we wanted to offer, but couldn't because of ABI
> > requirements. Whereas I was always looking at compounding library
> > support for larger and larger types as an odious requirement that
> > intmax_t helped us avoid.
> >
> > I *do* think there is demand for being able to compute with
> > larger-than-int64 integer types, and this is a good thing, but it's a
> > problem _BitInt solves entirely without imposing any heavy library
> > requirements. I don't think "printing a 128 bit number in decimal" is
> > very useful functionality. Hex, maybe, but then 256+ is really what
> > you would want (for key material etc).
>
> I don't think that that particular feature is very useful
> functionality, we agree on that. It is just part of the catalogue that
> is needed to claim proper 128 bit support.
128-bit support is not a feature we've ever claimed.
> Other features are probably more useful, such as checked arithmetic
> and the bit operation interfaces. These also come with C23, but for
> _BitInt types only if there is a fixed width type with the same width.
>
> > I'm sorry for sending you down a road of implementing this stuff in
> > a way that'd be plausible for inclusion in musl based on a
> > misunderstanding that it was a requirement for C23 support.
>
> This will come in other C libraries, anyhow. And this is not an
> extension outside the standard. The standard clearly describes how and
> when this has to be or can be done.
Maybe it will, maybe not. musl is intentionally not on the bleeding
edge of doing extensions. We aim to support the things the standard
guarantees to be present, and things which there is compelling
existing support (by other implementations) and demand (by
applications) for.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
