Re: [musl] [PATCH v2 1/1] vfprintf: support C2x %b and %B conversion specifiers

[Gabriel Ravier <gabravier@gmail.com>]

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ₑₙₛ
>