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_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29353 invoked from network); 19 Sep 2022 18:00:08 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Sep 2022 18:00:08 -0000 Received: (qmail 5370 invoked by uid 550); 19 Sep 2022 18:00:05 -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 5332 invoked from network); 19 Sep 2022 18:00:05 -0000 Date: Mon, 19 Sep 2022 19:59:52 +0200 From: Szabolcs Nagy To: Rich Felker Cc: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt , musl@lists.openwall.com Message-ID: <20220919175952.GB2158779@port70.net> Mail-Followup-To: Rich Felker , =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt , musl@lists.openwall.com References: <20220908163649.634728-1-gabravier@gmail.com> <20220912135904.GI9709@brightrain.aerifal.cx> <20220912164251.53a32cac@inria.fr> <20220919150916.GP9709@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20220919150916.GP9709@brightrain.aerifal.cx> Subject: Re: [musl] [PATCH] vfprintf: support C2x %b and %B conversion specifiers * Rich Felker [2022-09-19 11:09:17 -0400]: > On Mon, Sep 12, 2022 at 04:42:51PM +0200, J=E2=82=91=E2=82=99=E2=82=9B Gu= stedt wrote: > > There is one big addition, though, for the decimal floating point > > types, but support here is optional. I don't know if there is already > > an open stand-alone implementation of that stuff, but I think that > > that should be the goal, instead of repeating the effort for every C > > library implementation that is out there. >=20 > What do these entail? It looks like there's a requirement for printf > to support them, so I don't see how you'd do that as a separate > library. It looks like __STDC_IEC_60559_DFP__ is optional though, so > maybe we could just decline to define it and leave the support > sporadic at the level the compiler supports, as an extension rather > than part of the standard-specified functionality? it seems there is https://github.com/libdfp/libdfp/tree/master/printf-hooks using glibc specific apis (register_printf_specifier) i'm not sure how musl can handle this internally since we dont know in advance if the user links against libdfp.