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 13162 invoked from network); 20 Sep 2022 14:46:35 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Sep 2022 14:46:35 -0000 Received: (qmail 30446 invoked by uid 550); 20 Sep 2022 14:46:31 -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 30414 invoked from network); 20 Sep 2022 14:46:31 -0000 Date: Tue, 20 Sep 2022 10:46:18 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: musl@lists.openwall.com Message-ID: <20220920144617.GQ9709@brightrain.aerifal.cx> References: <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> <20220920141517.GP9709@brightrain.aerifal.cx> <20220920162236.38485fe3@inria.fr> <20220920162728.76fd9836@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220920162728.76fd9836@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:27:28PM +0200, Jₑₙₛ Gustedt wrote: > on Tue, 20 Sep 2022 16:22:36 +0200 you (Jₑₙₛ Gustedt > ) wrote: > > > There is a feature test macro for the maximum width of bit-precise > > integers, `BITINT_MAXWIDTH`. It is guaranteed to be at least > > `ULLONG_WIDTH` but can (and will) be larger on many platforms. > > e.g on my ubuntu-nothing-fancy machine I get > > clang -E -dM -xc /dev/null | grep -i bitint > #define __BITINT_MAXWIDTH__ 128 As I understand it, that gives the application knowledge of what bit-precise types the compiler can provide to it, but doesn't do anything to tell the application what wN modifiers printf can be expected to support. If it were required to support wN for N==BITINT_MAXWIDTH that would at least be something to go from, but I see no such requirement and I'm not sure it's desirable (it means you can't let the compiler offer larger BITINT_MAXWIDTH, but would have to define it as what libc supports). I think a separate macro indicating what printf supports is needed to solve this problem well. Rich