On Wed, Sep 6, 2023 at 9:38 AM Robert Elz <k...@munnari.oz.au> wrote: > Adding a different %b to printf(1) wasn't currently even proposed, just > deprecating the current one so it wouldn't conflict with the usage of > %b in printf(3) (which is being defined in C23, and is apparently already > firmly entrenched, even though C23 is not yet (quite) formally released). > > There was no proposal (yet) to provide a replacement for %b (which would > not actually be deprecated, if it were to be, for ages yet) - though the > %#s idea was proposed, and implemented in a couple of places (incl bash > I believe) - technically according to the rules, it would be too late now > to even mention that in the upcoming POSIX version, though there was some > talk of bending that rule, so a hint could be provided to applications as > to how they might move away from %b (the existing proposal is nonsense). > > My guess is that none of this will happen now, and %b, or possible alternates, > won't get any special mention in the forthcoming POSIX standard - so %b > in printf(1) would remain just like it is now for several decades at least. > (%b will appear in POSIX printf(3) in the next version after this one, > when POSIX aligns itself with C23 (or later) which contains that - C23 is > too late to be considered for the forthcoming POSIX version, and C17 does not > contain %b in its printf function).
Thanks. This entire discussion is nonsense; a proposal to deprecate a useful feature appears out of the blue, patches are sent, alternatives are listed, a whole fuss is made. Yet the only argument supporting said deprecation is maintaining consistency with C23. Why is it important to do that? No answer. It's nonsense. I don't think bash should deprecate %b. If a built-in way to convert to/from bases other than 8 and 16 is desired, bash can do it like ksh does or invent a new way. But breaking backwards compatibility so that you can say "well, at least my shell is consistent with C23" would be plain idiocy. > > kre > >
