RFC: 6178739 - Formatter - Zero padding flag with zero width

[Brian Burkhalter]

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