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.0 required=5.0 tests=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 20502 invoked from network); 5 May 2023 12:40:54 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 5 May 2023 12:40:54 -0000 Received: (qmail 17712 invoked by uid 550); 5 May 2023 12:40:50 -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 17674 invoked from network); 5 May 2023 12:40:49 -0000 Date: Fri, 5 May 2023 08:40:36 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: JeanHeyd Meneide , musl@lists.openwall.com, enh , =?utf-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1byk=?= , Jason Ekstrand Message-ID: <20230505124036.GI4163@brightrain.aerifal.cx> 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> <20230505085641.1ae2ca91@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230505085641.1ae2ca91@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] C23 implications for C libraries On Fri, May 05, 2023 at 08:56:41AM +0200, Jā‚‘ā‚™ā‚› Gustedt wrote: > 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 > > 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. > > > > 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. ā€¦ > > 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. FWIW, from the musl side, my assessment of this risk is that it makes no sense at all. The features you get are accessible only with hard-coded knowledge of your implementation; they aren't even detectable via probing. And unless you're a behemoth with effective veto power, there's always a risk that future official or de facto standards will impose conflicting requirements for whatever you assigned a custom meaning to. Rich