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=-0.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9379 invoked from network); 15 Apr 2023 13:16:04 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 15 Apr 2023 13:16:04 -0000 Received: (qmail 13812 invoked by uid 550); 15 Apr 2023 13:16:01 -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 13780 invoked from network); 15 Apr 2023 13:16:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681564549; x=1684156549; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=x24TTEjV1e1eBFa75Itt4FhXQ110xmxrxK/YeWzfhrY=; b=MXBn+OY8whkHq+1dV1YqCcnmqugL3/xLpleB/f0+uGYpWbYgHmrDL1QQQfcaCyZplo 8UWEwGRQcAOqEoKNo4p8o6JB2GIeuSBzj+ntPcQqiO+iwpM1c8B996DwOGbHzQUfodoq 35XEEeXDKc0+iBW5p1zxlPYB7npT2TcI9w0+JHrkQ2nJrowLOL0XQ/R0SdRUSBvU91Zk PYEhTlIBRIHRwq6twDGVL/iPLlZdwat8o85hOS/Pg8z0zuKHmybq1Mhawf5wJDnp7ZUf D8hXqYL7AXSY8rFtJAIHHgjIM7e9cFhFB3VEflFBAY/gGLOx0eXrxtVuCi50QUWfqStX hf9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681564549; x=1684156549; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=x24TTEjV1e1eBFa75Itt4FhXQ110xmxrxK/YeWzfhrY=; b=KabEThXMeImy4h7t4BTyhFFwm+ALyTi0w5NAVK2326qU40Cssh3d5MufBHJ5sK6R18 A1Q9fDHJvwIWDvNekS/ueq9vA8+5WluajO/Hqj0JUtVPelqht2m/wqGwi85vXwaURo+k raCjIcBrMn2znpUBAQojSmP4ZBk7QB8MTKMOsJH+O69dCikJIPv3iT3CVtqDxzM6Xpbq Me6UnAbxiVX0C3vt1Q/S0QV4Zf3YISGW36pC58UDDEj86zLJcDEbAcjddvVl8l6PDKFo t3r6lZLTNvEDzQFpu4KrluKi8IxqSNhxX+1pkuTXwF6riJeayORKzw7eI0vXsGFYkC/N Qo/g== X-Gm-Message-State: AAQBX9fiizJipFXLc1lkmK2imRCg3jG7ARigQBWsWvLJnUAJGB+6rbbT td3qsL87uhVAA5ioquRDgMqmifZTqHSVUQ== X-Google-Smtp-Source: AKy350aei18JSoYfmjaCarfQspsJs3t+rgpJvdiSpPvjz1aiQuW84wYMNAREr8aC9tTwKalYcSXAsw== X-Received: by 2002:adf:f88a:0:b0:2f5:3fa1:6226 with SMTP id u10-20020adff88a000000b002f53fa16226mr1370996wrp.14.1681564549406; Sat, 15 Apr 2023 06:15:49 -0700 (PDT) Message-ID: Date: Sat, 15 Apr 2023 15:15:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Content-Language: en-US To: =?UTF-8?B?SuKCkeKCmeKCmyBHdXN0ZWR0?= Cc: musl@lists.openwall.com References: <20220908163649.634728-1-gabravier@gmail.com> <20230415145242.6ec51d69@inria.fr> From: Gabriel Ravier In-Reply-To: <20230415145242.6ec51d69@inria.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [musl] [PATCH v2 1/1] vfprintf: support C2x %b and %B conversion specifiers On 4/15/23 14:52, Jₑₙₛ Gustedt wrote: > Hi, > I was just working on these things, too. So great, one thing less on > my list. > > Patch looks fine, but for the parts with the prefix, which I find > suspicious, anyhow, too much black magic for me. The parts with the prefix could instead be implemented as something like `"0B0b"+((t=='b')<<1)` (or something even cleaner, though it'd be a bit more verbose too) but I figured it was better to keep the same code style as for the hexadecimal conversion for now - changes to make it be less like black magic seem more like code style cleanup that probably aren't appropriate to put in the same patch (I suppose it also shaves off a single byte to do it the way its done right now, since a separate string would require an extra null terminator, and I highly doubt most compilers right now are able to figure out it's unneeded - to avoid taking an extra byte of space would require making a special array just for `0B0b` that specifically has a size of 4). > > What is still missing then, is to add PRIxYYY macros. With the latest > draft > > https://open-std.org/JTC1/SC22/WG14/www/docs/n3096.pdf > > these become mandatory feature tests for this feature. I already have > a patch for that. Nice to have a patch for that too, thanks. I wasn't planning on adding them myself, mostly because I don't really have any tests for them (as opposed to the b/B conversion specifiers which I have plenty of tests for) and don't plan on adding any anytime soon. > > I also have already patches for > > - the wN and wfN length modifiers > > - an extension towards `[u]int128_t` > > - adding the `*_WIDTH` macros > > And I will soon be starting on the similar features for `scanf` and > friends. There is one problem zone for that, namely that `0b` prefixes > are not only extensions but change semantics of existing executables > that would be linked against different versions of the C library. > > My plan is to make the distinction deep down in `__intscan` and have > that internal function in two versions `__intscan_c17` and > `__intscan_c23`, say. Doesn't the same apply to strto{,u}l{,l} given the behavior change is caused by the corresponding change in those functions ? > > Thanks > Jₑₙₛ >