Skip to content

fix: show 1.0 MB instead of 1024.0 kB in ByteCountDecimal - #1414

Merged
schollz merged 2 commits into
schollz:mainfrom
ChandraChaan:fix/bytecount-rounding
Nov 2, 2026
Merged

schollz merged 2 commits into
schollz:mainfrom
ChandraChaan:fix/bytecount-rounding

Conversation

@ChandraChaan

Copy link
Copy Markdown
Contributor

ByteCountDecimal picks the unit with integer division and then prints the value with %.1f, so a size just below a unit boundary is shown as 1024.0 of the smaller unit. For example 1048575 bytes: n = 1048575 / 1024 = 1023, the loop doesn't run, and 1023.999… is printed as 1024.0 kB. The same happens below every larger unit (1<<30 - 1 → 1024.0 MB). These strings appear in the send and receive messages and in the store listing.

When the rounded value is 1024.0, it now moves up one unit, so those sizes print as 1.0 MB and 1.0 GB. Other values are unchanged.

Extended TestByteCountDecimal with 1024*1024-1, 1024*1024*1024-1, and 1023*1024 (which must stay 1023.0 kB).

I ran CI on my fork:

Security portability regressions (macos-15) was cancelled after 15 to 19 minutes on my fork both with and without the fix (it takes about a minute here), so I couldn't get a result for it.

The unit is chosen with integer division, but the value is then printed
with %.1f, so sizes just below a unit boundary were shown as 1024.0 of
the smaller unit, e.g. 1048575 bytes as "1024.0 kB" in the send and
receive messages.

When the rounded value is 1024.0, move up one unit.
@schollz

schollz commented Nov 2, 2026

Copy link
Copy Markdown
Owner

thanks!

@schollz
schollz merged commit 4fc5ac0 into schollz:main Nov 2, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants