[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cc5e0c93-9aee-f287-fcfa-37829437dd9b@gmail.com>
Date: Sat, 15 Apr 2023 15:15:48 +0200
From: Gabriel Ravier <gabravier@...il.com>
To: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
Cc: musl@...ts.openwall.com
Subject: Re: [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ₑₙₛ
>
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.
