Fix printf conversion of a zero value with a precision of zero

[sachhg]

Summary

C requires that converting a zero value with a precision of zero produces no characters (C99 7.21.6.1p8, "The result of converting a zero value with a precision of zero is no characters"). fmt::printf prints 0 instead. This affects d, i, o, u, x and X.

Reproduction

format	value	C printf	fmt::sprintf
%.0d	0	``	0
%.d	0	``	0
%.0x	0	``	0
%5.0d	0	␣␣␣␣␣	␣␣␣␣0
%-5.0d	0	␣␣␣␣␣	0␣␣␣␣
%+.0d	0	+	+0
% .0d	0	␣	␣0
%#.0x	0	``	0

Found by diffing fmt::sprintf against snprintf across the flag, width and precision combinations for diouxXfFeEgG. A nonzero value, or any precision above zero, was already correct.

Changes

write_int now emits no digits when the precision is zero and the value is zero. The prefix, the sign and the width padding are unaffected, which is what C requires: %+.0d still yields + and %5.0d still yields five spaces.

%#o is the one exception in C: "if the value and precision are both 0, a single 0 is printed". printf.h clears alt for a zero value before the conversion specifier has been parsed, so it now remembers that case and raises the precision to 1 for octal. That mirrors how the standard states the rule, as # increasing the precision when necessary to force a leading zero.

This is scoped to printf by construction. The format API rejects a precision for integer arguments (fmt::format("{:.0}", 0) throws invalid format specifier), so write_int can only see a nonnegative precision through printf.

Testing

Added printf_test.zero_int_with_zero_precision, covering every affected conversion, the #o and #x cases, the sign, space and width interactions, and unaffected cases such as %.0d with 42 and %.1d with 0. Every expected value in it was generated from the platform snprintf rather than written by hand. EXPECT_PRINTF also exercises the positional form of each.

The test fails on main, producing 0 where the empty string is required. All 22 ctest targets pass with the change.

Not included

The same sweep showed that fmt::printf applies the + and space flags to the unsigned conversions o, u, x and X, where C ignores them, so %+x of 0 gives +0 rather than 0. C calls those flags undefined for conversions other than signed ones, so it is a compatibility difference rather than a conformance bug, and it seemed better kept out of this change. Happy to open a separate PR if you would like it matched to the common implementations.

[vitaut]

Thanks for the PR. Please keep the printf-specific logic in fmt/printf.h only.

[sachhg]

Moved it into printf.h in 1fcee22. format.h is back to what it was, and printf_arg_formatter now writes only the sign and padding when a d, i, o, u, x or X conversion has a zero value and a precision of zero. The printf and format tests pass.

[vitaut]

alt_zero is computed before the length conversion, so e.g. %#.0hho with 256 misses the octal-zero special case after hh converts the value to 0. Could we move the alt/zero handling after convert_arg and parsing the presentation type instead?

[sachhg]

Updated in d31459c. alt_zero is now evaluated after convert_arg and presentation type parsing, so converted values like %#.0hho with 256 correctly hit the octal zero special case. Test added in printf-test.cc as well.

[vitaut]

Negative dynamic precision is treated as zero by printf_precision_handler, but printf requires a negative * precision to be ignored, as if no precision had been specified.

This becomes observable with the new specs.precision == 0 check. For example:

fmt::sprintf("%.*d", -1, 0)

should produce 0, but with this change it produces an empty string. Similarly, %+.*d should produce +0.

Could we preserve the unspecified-precision sentinel for negative dynamic precision instead of clamping it to zero, and add a test for this case?

[sachhg]

Updated in 5bdbd45! printf_precision_handler now returns -1 (unspecified precision sentinel) when given a negative dynamic precision instead of clamping to 0. Tests added for fmt::sprintf("%.*d", -1, 0) (0) and fmt::sprintf("%+.*d", -1, 0) (+0). Thanks @vitaut!