And for those who have been following this issue, the new text for the forthcoming POSIX version has removed any mention of obsoleting %b from printf(1) - instead it will simply note that there is will be a difference between printf(1) and printf(3) once the latter gets its version of %b specified (in C23, and in POSIX, in the next major version that follows the coming one, almost certainly) - and to encourage implementors to consider possible solutions.
I've considered, and I don't see a problem needing solving, so I'm intending to do precisely nothing, unless someone actually finds a need for binary output from printf(1), which seems unlikely to ever happen to me (I mean a real need, not just to be the same as printf(3) "just because"). So, we can all go back to sleep now - and Chet, I'd undo $#s before it appears in a release, there's no need, and having it might eventually just cause more backward compat issues. And wrt: | I don't know what potential uppercase/lowercase pairs of format specifiers | are free from use in any existing POSIX-like shell, but my suggestion would There are none, printf(3) belongs to the C committee, and they can make use of anything they like, at any time they like. The best we can do is use formats that make no sense for printf(1) to support (like %p, which in printf(3) prints a pointer value, but in printf(1) there are no (meaningful) pointers that it could ever make sense to print, so %p is useless for its printf(3) purpose in printf(1). Similarly all the size modifier chars are meaningless for printf(1), as all the numeric values it is passed are actually strings - what internal format they're converted into is unrelated to anything the printf(1) user can control, so none of those size modifiers mean anything to printf(1) either (but it seems that many of those have been usurped by various printf(1) implementations already, so finding something free that everyone could use, isn't easy). kre
