Robert Elz wrote, on 02 Sep 2023:
>
> | 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?
I think everyone in the teleconference just assumed that the inconsistency
is best avoided. I don't recall living with it being discussed as an
option.
However, from the feedback it seems that enough people think "the cure
is worse than the disease" on this, and we should indeed consider
living with the inconsistency as another option.
> 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....)
This comes down to inconsistency again. Having two different purposes
for %p could be confusing for application writers.
However, if others think %p is a better choice than %#s I would not
object.
> 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.
In case you haven't seen it yet, we added a note in bug 1649 (on
field splitting) reminding you that we're waiting for your input.
Depending on the nature of the changes, it is still possible they
could make it into Issue 8. (If it needs an interpretation it is
unlikely the 30 day review would complete in time, but if it's a case
of "all shells do it this way, it's just that the standard didn't word
it quite right" then maybe it won't need an interpretation.)
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
