dd: Correct padding in status=progress

[tom_hur.st]

Summary

Output padding is specified via outlen, which is set using the return value of fprintf. Because it's printing that padding plus a trailing byte, it grows by one each iteration.

[kevans]

Hi @imp - I've also received some other questions about status=progress:

1.) What's the rationale for a mix of SI/IEC here? You deal professionally with larger storage and personally with smaller storage, so I assume there's a good reason for it. =)

2.) Any objection to making the final line of SIGINFO consistent with this?

[tom_hur.st]

Not just mixing SI/IEC, but they have different effective widths, so they scale differently - one will be counting up thousands of MBs while the other's totting up GiBs, (9294 MB, 8.7 GiB):

char si[4 + 1 + 2 + 1];         /* 123 <space> <suffix> NUL */
char iec[4 + 1 + 2 + 1];        /* 123 <space> <suffix> NUL */

If that's intended, shouldn't this be iec[3 + 1 + 3 + 1]? If it's not intended, char iec[4 + 1 + 3 + 1] is the obvious tweak for a more consistent (8407 MB, 8018 MiB), except then I also get (25 GB, ) if I dd with a larger block size(?!).

[tom_hur.st]

Oh, this is why:

humanize_number(persec, sizeof(iec), (int64_t)(st.bytes / secs), "B",

Formatting into persec but using the size of iec. I guess at high speeds it's filling the buffer and the trailing NULL is overflowing into iec.

[imp]

I listed both because different applications require different numbers.
Sometimes you need SI stuff since you are more familiar with that stuff due to there aspects of your pipeline (eg disks or networks)
Other times you want the IEC ones because you (eg memory images)
It's also not burdensome to do both, just tricky to get the code right...

[imp]

looks good, as does the good humanize_number catch.

[tom_hur.st]

Fix persec humanize_number call. Size IEC buffer to make room for the longer suffix.

[kevans]

In D16960#362030, @imp wrote:

looks good, as does the good humanize_number catch.

Do you want to take this through re@, or shall I?

[kevans]

Firing off an e-mail to re@