Re: printf(1) format additions

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Tue, 24 Jul 2018 at 13:49, Robert Elz <kre%munnari.oz.au@localhost> wrote:

> I have just added support for the F a and A formats to printf(1).
>
> These are not required by POSIX, but nor are the e E f g or G formats,
> which we did support. and supporting those 5 without the other 3 makes
> allmost no sense (in the code they are essentially free, the only real cost
> is a little more text in the man page).
>
> Those are done.
>
> But I also have support for the "data width modifiers" %ld %jx %Lf ...
> (all of them I believe, as supported by printf(3), though not all are fully
> supported., there is no %lc or %ls for example - those just generate
> errors.)
>
> These are also not required by POSIX.   They also mostly do nothing at
> all (do not in any way change the output) - with a couple of exceptions.
>
> Just like printf(3) %h truncates the argument to short (or unsigned short,
> as appropriate) and %hh truncates to char (or unsigned char).  And %Lf
> does (and all the other float formats with L do) use long double, rather
> than
> double.
>
> The point is just that it makes it easier to use printf(1) to test a
> proposed
> format string to be used with printf(3), and make sure that the appearance
> of the output is what you want, without needing to either recompile the
> program all the time, or write a one-off special program that takes a
> format
> string and data to print, and prints it (which is, really, what printf(1)
> is).
>
> At least 'l' (as in %ld) is supported in some other printf(1)
> imlementations.
>
> Any objections to adding support for these "data width" modifiers ?
>
> kre
>
>
No objections, I'd love to see these. I have trouble remembering printf
field specifiers, and almost always have to resort to a trial and error
compile-run-wtf frenzy when I least need it.

Thanks,
Alistair