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 9569 invoked from network); 20 Sep 2022 14:15:35 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Sep 2022 14:15:35 -0000 Received: (qmail 13532 invoked by uid 550); 20 Sep 2022 14:15:32 -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 13497 invoked from network); 20 Sep 2022 14:15:31 -0000 Date: Tue, 20 Sep 2022 10:15:18 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: musl@lists.openwall.com Message-ID: <20220920141517.GP9709@brightrain.aerifal.cx> References: <20220912135904.GI9709@brightrain.aerifal.cx> <20220912164251.53a32cac@inria.fr> <20220919150916.GP9709@brightrain.aerifal.cx> <20220919175952.GB2158779@port70.net> <20220919181039.GS9709@brightrain.aerifal.cx> <20220920111934.4dcdc985@inria.fr> <20220920122829.GM9709@brightrain.aerifal.cx> <20220920152929.66a33c9b@inria.fr> <20220920135553.GO9709@brightrain.aerifal.cx> <20220920160803.6bd6a422@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220920160803.6bd6a422@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] vfprintf: support C2x %b and %B conversion specifiers On Tue, Sep 20, 2022 at 04:08:03PM +0200, Jā‚‘ā‚™ā‚› Gustedt wrote: > Rich, > > on Tue, 20 Sep 2022 09:55:54 -0400 you (Rich Felker ) > wrote: > > > In general, offering non-portable functionality that applications > > can't already generally expect to have on popular systems, with no way > > to probe for availability, does not seem useful, and it's even less > > useful when there's a trivial portable way to do the same thing. > > Unfortunately, for the the bit-precise types there isn't. The > supported types may be wider than `long long` (128 and even 256 will > be common values that will probably widely supported) and then the > task of printing them gets as nasty as for today's `__int128`. My hope > was really to get all of these done for once, such that our users may > use their creativity to do more useful stuff. Well how are programmers supposed to probe what's available, and what are they supposed to do as fallback when support is not available? And what is the upper limit? Without answering those questions I don't see how this functionality can be made useful, because it's not even safe to use (you get UB if you guess wrong). The proposal on libc-coord for how to advertise feature availability (including at runtime via sysconf keys) addresses this kind of problem in general with extensions you can't just probe for with a configure-time link test, and might be the answer here... Rich