Re: [PATCH] printf: add %#s alias to %b

[Robert Elz]

    Date:        Thu, 7 Sep 2023 13:46:08 -0500
    From:        Eric Blake <eblake@redhat.com>
    Message-ID:  
<wa24ollawnix26bflu5v5bzmmlvxzq3j5643nfcju2xavsb7hg@carvl5tp7klv>

  | Right now, both bash and coreutils' 'printf %hhd 257' outputs "257",

ok, not unexpected.   I'm not sure its useful either.

  | but printf("%hhd", 257) in C outputs 1.

Yes.

  | 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.

Actually, I doubt you would, not really.  C has all kinds of fixed
bit width data types, and needs lots of infrastructure to deal
with that - the constants that give the max/min values, size
modifiers, so that either all the necessary bits can be fetched
from the arg, or we can pretend we only received the fewer number
we should have gotten, if only it weren't for the C arg data type
promotion rules.

The C example above is really an example of poor coding - not
incorrect, but relying on quirks that exist for other reasons.
The arg to %hhd should be an int8_t in which case it cannot be
257.  Having printf doing value masking in such a case is really
just to undo any unwanted effects from the promotion rules which
would apply if it really was an int8_t variable instead of a
consant.

Using those modifiers because you're too lazy to write the code
to mask the value yourself is just bad.

Printf(1) has none of all of that - apart from the single max
number of supported bits that applies, there are no magic
fixed bit width fields, no reason to specially bless 8, 16,
32 bit widths as more important than any other number.

Further the shell has most of the same arith capabilities as C
does, you can just as easily write your own masking expression
so you can pretend to have 19 bit wide ints if that were to
turn out to be useful.

The size modifiers aren't necessary, and aren't really useful
for the printf command, and just like C23's %b, aren't really
general enough.   We have enough non-portable sh level code
already, we don't need new added mechanisms that add to it.

  | 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) 

That implication was actually exactly the point - I still subscribe
to the 'do one thing, and do it well' philosophy.  That is, no
catch-all flags which enable a zillion different modifications,
all with one flag.  -b just for %b, -? (don't know what) for
size mod8fiers (just how many bits does (or would) %zu print
in printf(1), and why?)   Etc.

Neither are really likely to be needed, IMO.

kre