Date: Sat, 2 Sep 2023 09:01:06 +0000
From: "Austin Group Bug Tracker via austin-group-l at The Open
Group" <austin-group-l@opengroup.org>
Message-ID: <c5095e07efac34eee81bc2f025b30...@austingroupbugs.net>
| If we don't deprecate %b now, the alternative is to deprecate it in Issue 9
Why? I don't mean why is that not a consequent of the condition, but
why is it the only one? Why not "don't deprecate %b in printf(1) at all" ??
| Issue 9 will have an inconsistency between the printf() function and the
| printf utility.
Yes. And exactly why is that a problem? Has anyone seen any demand for
the printf utility (printf(1)) to output binary in the 0bxxxx format?
I haven't.
| and add %#s in draft 4. There is already a patch for coreutils
| printf, but I think we would need buy-in from at least one other printf
| implementation to even consider doing that.
I looked at our implementation, and while it would take more code
than has been described as required for the coreutils version, it
would not be a significant amount (one issue is that our code does
not look at the printf(3) flags at all, simply skips them - then passes
the format string to printf(3) (except for %b and one or two other
weird cases that need special handling) as it was given to printf(1).
Any handling of '#' (and "'" which we already support as much as our
rather limited locale handling allows - that is, if it works for a C
program, it will work for a sh script using printf(1) as well) is all
currently done by printf(3). Not a huge change, all we need to do
is actually look for it, and then in the %s case, do %b handling
instead of %s handling if the # was present, but it isn't just nothing.
I didn't already add it, as whatever we do with %#s I cannot see a
time when %b in our printf(1) ever means anything different than it
does today, whatever the standard requires. I suspect that might be
true of most other implementations as well - there is simply too much
application code using it to expect it to ever be changed, unless we
were to force it - and as long as %b keeps on working for applications,
they have no real reason to ever want to change, hence I don't really
forsee a time when almost anything would use %#s if we did add it.
It is different when superior functionality is replacing something
inferior (like printf and echo, or fgets() and gets()) but when we
would be just offering the exact same thing, with a different name,
and the old one still works anyway ???
Further, I suspect it is more likely that some future version of C
will find a need to define a meaning for %#s (and %S, and almost
anything else they haven't already defined) than there will ever be
a demand for 0b output from printf(1) via a dedicated conversion
character - a more general form allowing multiple bases perhaps, but
not just that. If we had to pick something as a replacement for %b,
I'd be choosing %p - ignoring its printf(3) usage, which makes no
sense at all in printf(1), it is more natural ("print") IMO than even
%b was, and has zero chance of being usurped by the C committee (and
would be easier for me to implement....)
kre
ps: while I'm here (first time on the list for a while) apologies for
my absence, my system broke, and for a whole set of weird reasons, took
a long time (close to 2 months) to get repaired, so I haven't been
following anything of what has been happening here until the back end
of this past week (not what has been happening in NetBSD either).
All my e-mail accumulated on munnari, so nothing was lost, but I am
nowhere near caught up.
