Date: Thu, 7 Sep 2023 13:46:08 -0500 From: Eric Blake <ebl...@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