Date: Thu, 21 Dec 2017 21:38:03 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 224498] ls -lh dose not display properly around 1MB, 1GB, ... Message-ID: <bug-224498-8-mmzFhFPxO1@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-224498-8@https.bugs.freebsd.org/bugzilla/> References: <bug-224498-8@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224498 --- Comment #3 from Pawel Biernacki <pawel.biernacki@gmail.com> --- Please see https://reviews.freebsd.org/D13578 for proposed patch. 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). -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-224498-8-mmzFhFPxO1>