Date: Tue, 20 Sep 2022 10:15:18 -0400 From: Rich Felker <dalias@...c.org> To: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr> Cc: musl@...ts.openwall.com Subject: Re: [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 <dalias@...c.org>) > 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.