On Tue, 2026-04-21 at 07:53 +0300, Andy Shevchenko wrote: > On Tue, Apr 21, 2026 at 6:38 AM Shuvam Pandey > <[email protected]> wrote: > > > > Well firstly I would note that the original behaviour isn't a > > > bug. > > James, thank you for the prompt reply! > > > So I agree this should not go forward as a bug fix in its current > > form. I'll drop this patch here and revisit it only if I can come > > back with a better understanding of the intended semantics. > > Shuvam, perhaps we need to add a few more test cases first to > understand current behaviour better?
Sure, but the base 2 one is the problem. It will go up to 1023 in whatever units but for binary that's under 1 of the next unit up. So 1023 B == 1.00 KiB 1018 B == 0.99 KiB 1000 B == 0.98 KiB And so on. However, technically the latter two (when converted to the upper unit) are only 2sf not 3 because the leading zero doesn't count. If you run the above to 3sf it comes out 1023 B == 0.999 KiB 1018 B == 0.994 KiB 1000 B == 0.977 KiB If the desire is really to be 3sf everywhere, you need the latter and the routine can be adjusted to do that: the while around the do_div would have to be checking strictly >= 1000 and you now have to set j=0 if size comes out 0. Rounding also has to be done inside that loop now (because too much precision is lost in the j = 3 case). But, like I said, this isn't a bug fix it's a behaviour change. Regards, James
