Summary
When --suffix contains non-ASCII characters and --format=%Nf requests padding, uutils and GNU produce different padding. ASCII suffixes agree exactly.
Found by fuzz_numfmt.
Reproduction
$ LC_ALL=C /usr/bin/numfmt --suffix=🔗 --format=%17.2f 692
692.00🔗
(no leading spaces)
$ LC_ALL=C target/debug/numfmt --suffix=🔗 --format=%17.2f 692
692.00🔗
(7 leading spaces)Same with other multi-byte suffixes (`中`, `Ã`, …). Single-byte ASCII suffixes behave identically on both:
$ numfmt --suffix=AB --format=%17.2f 692 # both: ' 692.00AB'
GNU's width calculation seems to deduct the suffix length in a way that makes the full output (including suffix bytes) come out at something ≤ 17, while uutils pads the number portion to width - ascii_byte_len(suffix) regardless of suffix encoding.
Not yet clear which behavior is correct (GNU's is locale-aware; in LC_ALL=C it's arguably ambiguous), but the two should agree.
Summary
When
--suffixcontains non-ASCII characters and--format=%Nfrequests padding, uutils and GNU produce different padding. ASCII suffixes agree exactly.Found by
fuzz_numfmt.Reproduction
Same with other multi-byte suffixes (`中`, `Ã`, …). Single-byte ASCII suffixes behave identically on both:
$ numfmt --suffix=AB --format=%17.2f 692 # both: ' 692.00AB'GNU's width calculation seems to deduct the suffix length in a way that makes the full output (including suffix bytes) come out at something ≤ 17, while uutils pads the number portion to
width - ascii_byte_len(suffix)regardless of suffix encoding.Not yet clear which behavior is correct (GNU's is locale-aware; in
LC_ALL=Cit's arguably ambiguous), but the two should agree.