On Jun 26, 2013, at 10:55 PM, David DeHaven wrote:
>>> Specifically, I was referred to how C handles "%0.4f\n".
>
> No width, decimal truncated (rounded? floored? I forgot which it is) to four
> digits.
>
> -DrD-
>
>>> printf("%0.4f\n", 56789.456789F);
> ...
>>> 56789.4570
>> ^ ^ ^ ^ ^ ^ ^ ^
> ...
>> "A leading zero in the width value is interpreted as the zero-padding flag
>> mentioned above […]."
>
> Only if there's a valid width following, which there isn't in the case above.
> Try "%016.4" with the above test. Note that the width is the *full* width of
> the entire field, including decimal point and following digits.
>
> printf("%016.4f\n", 56789.456789F);
> printf("%0.4f\n", 56789.456789F);
>
> Produces:
> 00000056789.4570
> 56789.4570
printf("%016.4f\n", 56789.456789F);
printf("%1.4f\n", 56789.456789F);
printf("%0.4f\n", 56789.456789F);
produces (on Mac OS X)
00000056789.4570
56789.4570
56789.4570
whereas
System.out.printf("%016.4f\n", 56789.456789);
System.out.printf("%1.4f\n", 56789.456789);
System.out.printf("%0.4f\n", 56789.456789);
produces
00000056789.4568
56789.4568
Exception in thread "main" java.util.MissingFormatWidthException: %0.4f
Two possible solutions are:
1) Change the specification of the width field to
"The optional width is a positive decimal integer indicating the minimum
number of characters to be written to the output. A leading zero in the width
value is interpreted to be the zero-padding flag discussed below."
2) Handle a 0.x as indicating zero width, not zero padding.
Brian
