For further comparison, the man page for PRINTF(1) on Mac OS 10.7.5 states
Field Width:
An optional digit string specifying a field width; if the output
string has fewer characters than the field width it will be
blank-padded on the left (or right, if the left-adjustment indi-
cator has been given) to make up the field width (note that a
leading zero is a flag, but an embedded zero is part of a field
width);
and that for printf(3) on Ubuntu 12.04
The field width
An optional decimal digit string (with nonzero first digit) specifying
a minimum field width. If the converted value has fewer characters
than the field width, it will be padded with spaces on the left (or
right, if the left-adjustment flag has been given). Instead of a deci‐
mal digit string one may write "*" or "*m$" (for some decimal integer
m) to specify that the field width is given in the next argument, or in
the m-th argument, respectively, which must be of type int. A negative
field width is taken as a '-' flag followed by a positive field width.
In no case does a nonexistent or small field width cause truncation of
a field; if the result of a conversion is wider than the field width,
the field is expanded to contain the conversion result.
Ubuntu Linux and Mac OS X show the same behavior for
printf("%0.4f\n", 56789.456789F);
which is to print
56789.4570
This looks as if the default width is taken to be zero. Adopting this behavior
for Formatter however would look to be in violation of its specification
'0' '\u0030' Requires the output to be padded with leading zeros to
the minimum field width following any sign or radix indicator except when
converting NaN or infinity. If the width is not provided, then a
MissingFormatWidthException will be thrown.
On Jun 26, 2013, at 10:31 AM, Brian Burkhalter wrote:
> "A leading zero in the width value is interpreted as the zero-padding flag
> mentioned above […]." [1]
[1] https://en.wikipedia.org/wiki/Printf#Format_placeholders
