Date: Tue, 05 Sep 2023 22:32:39 +0200
From: Dragan Simic <dsi...@manjaro.org>
Message-ID: <7cfed11b50d35cbfaaa647c1fcd39...@manjaro.org>
| Are there any official explanations why is the invalidation actually
| happening now?
It was proposed because of a desire to keep the formats for printf(1)
and printf(3) the same (they're not really anyway, but they generally
don't actually conflict currently).
No invalidation would be happening now, merely a note in the coming standard
that the %b in printf(1) would (might) be removed in a later version of
the standard - so implementations have time to implement something to
replace it, and applications to stop using %b in printf(1). The next
version of the standard isn't likely for at least another decade (the
coming one isn't finished yet, and that's not the next that counts here,
and later issues that are merely corrections (TCs) don't count either).
[As a reference for timelines, the current POSIX standard is from 2008,
though a couple of TCs have followed it - that's 15 years already
between versions.]
However, my "read of the room" at the minute is that this simply won't
happen, and printf(1) %b will remain as it is, and not be removed any
time soon (or probably, ever). If printf(1) ever really needs a method
to output in binary, some other mechanism is likely to be found - most
likely one which gives a choice of output bases, not just base 2.
There's no current harm implementing %#s as an alias for %b - but I see
no point in anyone using it, it will certainly be far less portable than
%b for a LONG time. There's also no guarantee that the C people might not
find a use in printf(3) for %#s (currently the # there has no meaning) and
entirely possible that whatever that use is, if it happens, might be more
useful for printf(1) to follow, than having it mean what %b currently
means - so going that route really is not a safe long term choice (it
would be a gamble).
kre
