On Thu, Sep 07, 2023 at 11:53:54PM +0700, Robert Elz wrote:
> 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.
Indeed, at this point, even though I proposed a patch for %#s in
coreutils, I'm inclined to NOT apply it there.
The ksh extension of %..2d to output in binary does sound worth
replicating; I wonder if glibc would consider putting that in their
printf(3); and I could see adding it to Coreutils (whether or not bash
adds it - because ksh already has it).
And thanks for pointing out the existing discrepancy with %c; that was
really helpful in today's Austin Group meeting in realizing that
conflicts in Issue 9 regarding %b is not covering new ground.
>
> 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).
Here, I slightly disagree with you.
Right now, both bash and coreutils' 'printf %hhd 257' outputs "257",
but printf("%hhd", 257) in C outputs 1. I would LOVE to have a mode
(possibly spelled 'printf -C %hhd 257') where I can ensure that width
modifiers are applied to the integer value obtained from the correct
subsequent argument to printf.
[Side note: since bash also supports 'printf a%n b >/dev/null' as a
convoluted way of accomplishing 'b=1', I wonder if it would be
possible to port https://github.com/carlini/printf-tac-toe which
performs an interactive game of tic-tac-toe in a single printf(3)
statement invoked in a while loop into a single printf(1) command line
invocation. The lack of %hhd implicitly masking with 256 makes it
harder]
That is, if we are thinking about adding 'printf -c' or 'printf -C' as
a way to say "treat my format string as closely to C as possible", we
would be addressing MULTIPLE things at once: %b, %c, %hhd, and any
other (useful) conversion specifier in C. And given that, I prefer
naming such an extension option -C or -c (implying C-like), rather
than your suggestion of -b (implying binary, but where the implication
only benefits %b) as a better option name for such a printf extension
option.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org
