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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12244 invoked from network); 3 May 2023 09:13:04 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 3 May 2023 09:13:04 -0000 Received: (qmail 15931 invoked by uid 550); 3 May 2023 09:13:00 -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 15899 invoked from network); 3 May 2023 09:12:59 -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=HTBNDPzwEdPPSqdr0rWI7Bam7WJGGsYLqkFp5ZrU/MU=; b=Ofov1AZ52n3cRnP4ma0zIzcaWb+LgvVGYHsaKHE2ToHrXtb83uUJ9sqj vDmrs1tYo/x//oKB2DUc224LxCCqBLWYK09E8/1w1/DVsUgk/ac4chbLH wDa4asHaPmzHpq7ET/OpnS6Vl2PUpaEAn3r9ZRTjNUq/5defb8pD6W7b7 M=; Authentication-Results: mail3-relais-sop.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="5.99,246,1677538800"; d="scan'208";a="54954762" Date: Wed, 3 May 2023 11:12:46 +0200 From: =?UTF-8?B?SuKCkeKCmeKCmw==?= Gustedt To: Rich Felker Cc: musl@lists.openwall.com Message-ID: <20230503111246.00ba409e@inria.fr> In-Reply-To: <20230503000045.GU4163@brightrain.aerifal.cx> References: <20230501205037.29e42745@inria.fr> <20230501194121.GS4163@brightrain.aerifal.cx> <20230502085740.23ff20d5@inria.fr> <20230502155903.30bee099@inria.fr> <20230502232009.GT4163@brightrain.aerifal.cx> <20230503000045.GU4163@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_/UpFK6s_qSSyNAtJg0Uesb6y"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: [musl] patches for C23 --Sig_/UpFK6s_qSSyNAtJg0Uesb6y Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rich, thanks for looking into this so quickly. on Tue, 2 May 2023 20:00:45 -0400 you (Rich Felker ) wrote: > Some more things I noticed, some of them general: >=20 > For compiler feature stuff like __has_c_attribute, this should not be > littered all over headers. We have features.h that already abstracts > getting the ones we need. If there are others strictly needed, those > should be abstracted there too. ok, I'll see that I group things that are needed together, there. > It's probably not needed to avoid exposing new functions under older > __STDC_VERSION. We generally do not aim for strict namespace > conformance to older versions of the standards. ok, that's politics, if you think that this is fine I'll go for it (Such a policy will be difficult to maintain, when there will be third party implemenations of the decimal floating point stuff. This will be some hundreds of new interfaces that had not been reserved. Also there will be a bunch of such functions in `math.h` even without decimal floating point which are not covered by these patches.) > On the flip side, it's not needed to jump through compiler-specific > hoops to get new features that can't be obtained in standard ways > without c23 mode. For example, nullptr_t does not need clang special > cases. If it's not c23, it just doesn't need to be defined (and in > fact strictly speaking it's a namespace violation to define it, but as > above we don't really care about that.) I see your point. `nullptr` is special in that it might also be provided as an extension in other standard modes by compilers, and tendency in clang, for example, could be to base `NULL` on that. Providing the `typedef` is then some nicety for our users. > It's not needed to make namespace-safe internal __-prefixed versions > of functions unless they're used to implement functions in a more > restrictive namespace profile. For example, POSIX functions needed to > implement STDC functions need this treatment, but STDC functions > basically never do. Ok, that simplifies things. And effectively this will give hard errors for applications that already use such names, even if they are dynamically linked. This probably is a good thing. > Language/compiler baseline for building musl is not going to go up, so > this complicates some things, especially implementing the int128 > stuff. This will need pop_arg to call out to an arch-provided asm > function that bypasses the C type system to get the nonexistent-type > argument off the va_list and store it in a pair of uint64_t. I don't see that. `pop_arg` just uses `va_arg` and that in turn is fixed to `__builtin_va_arg`. The proposed patches assume that if `__SIZEOF_INT128__` is defined by the compiler that then the compiler provides the `__int128` types and knows how to deal with them in `__builtin_va_arg`. Is there anything wrong with that assumtion? > There are not going to be different versions of scanf/strto* because > there's just no way to do that in a conforming way (the standard > allows declaring these functions yourself without including the > header, which would not get the remapping). Yes, sure. Applications that do that would receive the default treatment which is delivered with a given C library, much as for other legacy objects that had been compiled with previous versions. > As above, strict conformance to outdated versions of the standard is > just not a priority. musl's claim/target is conformance to current > versions only and sometimes, on a case-by-case basis, partial > support for older ones. Yes. But this here is really something to consider. Legacy executables that are linked dynamically may behave semantically different with this patch. This might even have security implications. E.g within musl itself in inet_aton.c there is a use with a base of `0` that could perhaps be abused to do spoofy things. > (Looking at it again, I don't understand how the code in your > repo was actually intended to provide different versions. __intscan, > etc. are not public interface boundaries and references to them never > appear in applications, only internally within libc. Your code seems > to be conditioning which gets used based on the STDC version in use > for building musl, which is completely decoupled from the version of > the standard that a given application is being built/linked for.) Yes, this is an attempt to cope with the situation, which is probably not yet final. I was hestitating to do the work of duplicate all the externally visible interfaces before we agree upon such an approach. The idea is that a C library provider (i.e Linux distribution) would have to decide which version to provide as a default for legacy executables. (Here this is done by using the C version with which the library is compiled, but other mechanisms would be possible.) Newly compiled code (but for the extremists that you mentionned above) would get the mode C17 or C23 under which they compile. 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_/UpFK6s_qSSyNAtJg0Uesb6y Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCZFIljgAKCRAP0+hp2tU3 4iPvAJ42Aep/WtS/1/EuaP6i63AoyqP5BQCfdzKSAk0zDKM0/apJ8TljVjxYnwk= =uLKE -----END PGP SIGNATURE----- --Sig_/UpFK6s_qSSyNAtJg0Uesb6y--