Sorry for the duplicate revision. I'm having curl problems.

Man: start a sentence from new line.

Add CAVEATS section to the man page to point out the rounding issue with too short buffers.

In D13578#284349, @kib wrote:

In one branch of the snprintf() use, we add divisor / 2 and remainder * 10, not remainder. Does this case need to be handled differently ?

In D13578#283995, @pawel.biernacki-gmail.com wrote:

In D13578#283989, @cem wrote:

I don't understand the actual algorithmic change, but given the strong test coverage, I think I'm ok with this. Some style nits below.

Issue was caused by the way the final value was calculated in snprintf call, where remainder and divisor/2 was added back to the divided number. If remainder + divisor/2 was larger than 1024, it added 1 to the final value. If the final value as already 999 (as in the example reported), that brought it to 1000. If the buffer length provided was 4 (as is the case with ls), that left no space for the unit character.
Same issue was also present for other numbers if too small buffer lengths where used.
The fix continues the division of the original number if the above case happens -- added the appropriate check to the for loop performing the division. This lowers the value shown, to make it fit into the buffer space provided (1.0M for 4 character buffer, as used by ls).

In D13578#283995, @pawel.biernacki-gmail.com wrote:

In D13578#283989, @cem wrote:

I don't understand the actual algorithmic change, but given the strong test coverage, I think I'm ok with this. Some style nits below.

Issue was caused by the way the final value was calculated in snprintf call, where remainder and divisor/2 was added back to the divided number. If remainder + divisor/2 was larger than 1024, it added 1 to the final value. If the final value as already 999 (as in the example reported), that brought it to 1000. If the buffer length provided was 4 (as is the case with ls), that left no space for the unit character.
Same issue was also present for other numbers if too small buffer lengths where used.
The fix continues the division of the original number if the above case happens -- added the appropriate check to the for loop performing the division. This lowers the value shown, to make it fit into the buffer space provided (1.0M for 4 character buffer, as used by ls).

Thank you for patch.
I apply this patch to 12.0-CURRENT r327074, the right value is shown with ls -lh.

In D13578#283989, @cem wrote:

I don't understand the actual algorithmic change, but given the strong test coverage, I think I'm ok with this. Some style nits below.

Address @cem comments about style(9).

I don't understand the actual algorithmic change, but given the strong test coverage, I think I'm ok with this. Some style nits below.

They already see it, they just don't know what to do once they are there.

In D4224#89049, @rodrigc wrote:

No, I don't want this in `/usr/share/docs`. This is meant to be *newbie* friendly so people can just go in /usr/tests
and figure out what to do relatively quickly by looking at the README.
The way to figure this out right now is confusing enough as it is with info scattered all over the place in different man pages,
wikis, etc. The end result is that newbies can't figure out what to do, and keep asking me.

No, I don't want this in `/usr/share/docs`. This is meant to be *newbie* friendly so people can just go in /usr/tests
and figure out what to do relatively quickly by looking at the README.
The way to figure this out right now is confusing enough as it is with info scattered all over the place in different man pages,
wikis, etc. The end result is that newbies can't figure out what to do, and keep asking me.

It seems like this should be installed to /usr/share/docs

In D3925#81904, @kib wrote:

In D3925#81898, @ngie wrote:

int rc;
ATF_CHECK_MSG((rc = foo()) == exp_result, "foo() failed. Expected: %d; got: %d");

This is extremely ugly. For my tests, the function is the same, but the arguments are what produce the test case. In essense, I have to either retype the same thing twice, or create a wrapper that would call ATF_CHECK_MSG() only in case of failure.

In D3925#81898, @ngie wrote:

int rc;
ATF_CHECK_MSG((rc = foo()) == exp_result, "foo() failed. Expected: %d; got: %d");

This is extremely ugly. For my tests, the function is the same, but the arguments are what produce the test case. In essense, I have to either retype the same thing twice, or create a wrapper that would call ATF_CHECK_MSG() only in case of failure.

Sidenote: the only thing that's slightly painful with ATF that other test infrastructures seem to do better is that ATF_CHECK/ATF_REQUIRE don't print out the result of the expression, so if you need to dump out the result of the check, use ATF_CHECK_MSG/ATF_REQUIRE_MSG instead, like:

Do not create temp file in /tmp. Use ATF_CHECK instead of ATF_CHECK_EQ.

Add VM_MAXUSER + 1, 0 test.

In D3925#81835, @emaste wrote:

Is it worth checking VM_MAXUSER_ADDRESS + 1, 0?

Is it worth checking VM_MAXUSER_ADDRESS + 1, 0?