From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12744 invoked from network); 31 May 2023 15:56:45 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 31 May 2023 15:56:45 -0000 Received: (qmail 15593 invoked by uid 550); 31 May 2023 15:56:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 15554 invoked from network); 31 May 2023 15:56:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:from:to:cc:subject:message-id:in-reply-to: references:mime-version; bh=RG6QFBET3KavHiHMDHoChqrBrwY/Bunz1nxOpk9AAMw=; b=Oaw57VBCEZDTq5Q+RGef9rlA6b5H9xnEnlFniY/r3XSIbMPauNIfT6d/ 7foVrdyV08dZSap4nTToriB3HMlWtEXnnsbyDX6IH+7HrENtuhPia/kYY 8iFwfTni5o/M/X8mUkhyq6Iou5qM0bBQf635XN7w0vwiuW+RdKdKi8JbB A=; Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=jens.gustedt@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="6.00,207,1681164000"; d="scan'208";a="110553459" Date: Wed, 31 May 2023 17:56:28 +0200 From: =?UTF-8?B?SuKCkeKCmeKCmw==?= Gustedt To: Rich Felker Cc: musl@lists.openwall.com Message-ID: <20230531175628.168043d2@inria.fr> In-Reply-To: <20230531154043.GH4163@brightrain.aerifal.cx> References: <1c8e850ed3190af39b9e3f501d79899d438e7292.1685536608.git.Jens.Gustedt@inria.fr> <20230531142743.GB4163@brightrain.aerifal.cx> <20230531163643.2a382b4a@inria.fr> <20230531144128.GD4163@brightrain.aerifal.cx> <20230531165545.29eb823f@inria.fr> <20230531145724.GF4163@brightrain.aerifal.cx> <20230531170700.65bd9c11@inria.fr> <20230531151406.GG4163@brightrain.aerifal.cx> <20230531173718.3d7d499f@inria.fr> <20230531154043.GH4163@brightrain.aerifal.cx> Organization: inria.fr X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) X-Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAACRQTFRFERslNjAsLTE9Ok9wUk9TaUs8iWhSrYZkj42Rz6aD3sGZ MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/fB4E1.=T19G/Z2oYLH6R3vu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: [musl] [C23 128 bit 4/4] C23: implement proper support for int128_t and uint128_t --Sig_/fB4E1.=T19G/Z2oYLH6R3vu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rich, on Wed, 31 May 2023 11:40:43 -0400 you (Rich Felker ) wrote: > On Wed, May 31, 2023 at 05:37:18PM +0200, J=E2=82=91=E2=82=99=E2=82=9B Gu= stedt wrote: > > Rich, > >=20 > > on Wed, 31 May 2023 11:14:06 -0400 you (Rich Felker > > ) wrote: > > =20 > > > On Wed, May 31, 2023 at 05:07:00PM +0200, J=E2=82=91=E2=82=99=E2=82= =9B Gustedt wrote: =20 > [...] =20 > [...] =20 > > > [...] =20 > > > [...] =20 > [...] =20 > > > [...] =20 > > > [...] =20 > > > [...] =20 > > > [...] =20 > [...] =20 > [...] =20 > > >=20 > > > 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. =20 > >=20 > > 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. > > =20 > > > 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. > > >=20 > > > 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). =20 > >=20 > > 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. =20 >=20 > 128-bit support is not a feature we've ever claimed. And I never said that. > > 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.=20 > > > 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. =20 > >=20 > > 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. =20 >=20 > Maybe it will, maybe not. musl is intentionally not on the bleeding > edge of doing extensions. Again, this is not an extension but an optional feature, and this has nothing of bleeding edge. This is present in compilers since ages, and everybody is using their specific ways to go around the restrictions of previous C standards. > 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. This is just a hen-and-egg problem. You will never see demand for [u]int128_t if you do not provide the tools. Everybody will just raise their eyebrows, swear on how dammed retarded they think the C committee would be, and then do some workaround. J=E2=82=91=E2=82=99=E2=82=9B --=20 :: ICube :::::::::::::::::::::::::::::: deputy director :: :: Universit=C3=A9 de Strasbourg :::::::::::::::::::::: ICPS :: :: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus :: :: :::::::::::::::::::::::::::::::::::: =E2=98=8E +33 368854536 :: :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt :: --Sig_/fB4E1.=T19G/Z2oYLH6R3vu Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCZHduLAAKCRAP0+hp2tU3 4oHqAJ9gvgNboZdOybW1wl8YhE3TwfapLQCePwmQdnhREkt9aqKoYISAA822ySk= =k50O -----END PGP SIGNATURE----- --Sig_/fB4E1.=T19G/Z2oYLH6R3vu--