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 10969 invoked from network); 5 May 2023 06:56:57 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 5 May 2023 06:56:57 -0000 Received: (qmail 19788 invoked by uid 550); 5 May 2023 06:56:54 -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 19747 invoked from network); 5 May 2023 06:56:54 -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=0xyXtM9bXxF+wEu2GdItxVAztssFoTyZz9GW6oMxJhg=; b=mL7KcL3qSt4ydwaBmz/m8XQnCeQU6DkDBeJz41mNoibRhA9qRvA6cE9o kUsYLyk0I6b0wQ57ASb49IGOhuADSR5X4eKUJomKcCRexyWKEoIRLolPp M/O1llvlPoq67TSmC1XAX8A9LT+PQdwzQxKQpR9TZmKavtPqoOZDX2PjV E=; 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="5.99,251,1677538800"; d="scan'208";a="106394178" Date: Fri, 5 May 2023 08:56:41 +0200 From: =?UTF-8?B?SuKCkeKCmeKCmw==?= Gustedt To: JeanHeyd Meneide Cc: musl@lists.openwall.com, enh , Rich Felker , "=?UTF-8?B?572X5YuH5Yia?=(Yonggang Luo)" , Jason Ekstrand Message-ID: <20230505085641.1ae2ca91@inria.fr> In-Reply-To: References: <20220923162518.56284329@inria.fr> <20221119153350.292e390b@inria.fr> <20230504081942.065fc12f@inria.fr> <20230504160304.GC4163@brightrain.aerifal.cx> <9ecc996a-5eba-404d-1b95-63398ea93543@gmail.com> 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_/aCrIjuYwBc9qT1QPLikph9m"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: [musl] C23 implications for C libraries --Sig_/aCrIjuYwBc9qT1QPLikph9m Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, on Thu, 4 May 2023 20:37:58 -0400 you (JeanHeyd Meneide ) wrote: > > for example, stuff like the %B specifier are technically optional > > given =20 > that the uppercase conversion specifier namespace wasn't reserved, > but iirc there's no known implementation of C that uses it for any > > other purpose. >=20 > There was apparently one implementation that was already using > %B as a kind of numeric printout (not for binary) that was reported > during the meeting and at a few other junctures, so unfortunately it > might not be fully portable. =E2=80=A6 Yes, in general I am always amazed to see how diversive and inventive C implementations are. So changing things even as innocent sounding like a format specifier or adding new function identifiers that could be conflicting with applications is usually watched very closely. There are really a lot of C implementations out there, and in general they use the design space that is offered to them. For format specifiers this is even more complicated. There are C libraries that provide interfaces to add such specifiers from user space. So here the risk for conflicts can not easily be assessed by WG14 (we don't have the data). So it should be left to the C library implementors to assess this risk. 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_/aCrIjuYwBc9qT1QPLikph9m Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCZFSoqgAKCRAP0+hp2tU3 4vQtAKCZNMDbdRVpteJj4QIRfj384H30zwCfQN+BzIwIeo0tPlDISI8P7TKQiXQ= =T3yX -----END PGP SIGNATURE----- --Sig_/aCrIjuYwBc9qT1QPLikph9m--