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 7521 invoked from network); 2 Jun 2023 07:58:30 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 2 Jun 2023 07:58:30 -0000 Received: (qmail 13729 invoked by uid 550); 2 Jun 2023 07:58:27 -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 13697 invoked from network); 2 Jun 2023 07:58:27 -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=rayiKjXMUC33gygsXNueM2jzfur6cJQ1h0kSZXSCTJs=; b=l+yLQBzM3PCowhUNlvBSYjBPChSeKJEPr1QGZ0lSjnrfOWSYZdPqhoPd No8Pb9CCnMfinblnE1i3gMiFOhjF3KvItnhA2d7BQEuzHHwGIfBnF3bXd if6m4O8UGUF8hPvhWMxFWX4o0gfVkh1LhwShtIJsMfK+niftLZBQub2I4 4=; 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,212,1681164000"; d="scan'208";a="110865835" Date: Fri, 2 Jun 2023 09:58:14 +0200 From: =?UTF-8?B?SuKCkeKCmeKCmw==?= Gustedt To: Szabolcs Nagy Cc: Rich Felker , musl@lists.openwall.com Message-ID: <20230602095814.4568f5ab@inria.fr> In-Reply-To: <20230601182223.GZ3630668@port70.net> References: <20230531195928.GJ4163@brightrain.aerifal.cx> <20230531230012.06369e12@inria.fr> <20230531213922.GK4163@brightrain.aerifal.cx> <20230601085842.2abf2921@inria.fr> <20230601182223.GZ3630668@port70.net> 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_/pjJOr_FtXaBiY4YQk4ej1sG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: [musl] Re: High-level C23 process requests --Sig_/pjJOr_FtXaBiY4YQk4ej1sG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Szabolcs, on Thu, 1 Jun 2023 20:22:23 +0200 you (Szabolcs Nagy ) wrote: > * J=E2=82=91=E2=82=99=E2=82=9B Gustedt [2023-06-0= 1 08:58:42 +0200]: > > Also, in the compiler community there does not seem to be much of a > > resistance to implement C23. clang and gcc are almost complete and > > probably will have all of C23 the day it will be officially > > published. They will then probably switch to C23 as a default one or > > two versions later, once the C library support is stable. =20 >=20 > well clang had _BitInt before it was in the standard.. this is just the hen-and-egg problem WG14 wouldn't standardize if there is no experience in the field, the field wouldn't dare to do anything novel if this is not imposed by some standard. So glitches like that are built into the process, luckily the clang people took the risk and went ahead to start it. (And they paid quite a price, having to rename the type, for example.) > which is a bit of a problem because ppl only now realize that its > abi is not what they want so various targets try to retroactively > specify the ps abi for it which may leave existing clang broken. yes This is also the principal reason, I think, why C23 doesn't impose function interfaces for these types, not even `printf` or `scanf` formats, nor for the new header. So all C libraries such as musl that delegate `va_arg` to compiler buitins should not be affected by this. > in any case i think standard conformance is a good thing in musl, but > we are not in a big hurry to implement c23, and can wait until clang > and gcc converge on abi for a couple of targets. As said, these ABI questions are not impacting C libraries. So I don't see how this would be an argument for (or against) integrating the things that we have, in particular the boring stuff. I am still much in favor to integrate this as soon as it is ready, be it for the simple reason to never talk about it again. Since I have your attention, there is also other "boring" stuff that I have not even tried to implement, most things concerning floating point functions. These are acospi, asinpi, atan2pi, atanpi, compoundn, cospi, fmaximum_mag_num, fmaximum_mag, fmaximum_num, fmaximum, fminimum_mag_num, fminimum_mag, fminimum_num, fminimum, nextup, rootn, roundeven, sinpi, tanpi, fadd, dadd, fsub, dsub, fmul, dmul, fdiv, ddiv which get the usual three function interfaces and the tg-macro in . For someone with experience in FP like you these are probably not a big deal, it is just that there are finally a lot more than I thought. I personnally don't think that I have the skills for these functions. Thanks 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_/pjJOr_FtXaBiY4YQk4ej1sG Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCZHmhFgAKCRAP0+hp2tU3 4t2dAKCLcS8S47QZnGaRZ8pReozer6LGRQCfbavV7mzdc8lC5pCk2BDGSSsWiqY= =Dukr -----END PGP SIGNATURE----- --Sig_/pjJOr_FtXaBiY4YQk4ej1sG--