Conversation
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
oomm stops dividing once it reaches the largest prefix, so for inputs at or above 2^63 QB the leftover quotient no longer fits an int64 and n.Int64() hands back the truncated low bits: BigBytes(2^63 QB) prints "-9223372036854775808.0 QB", BigBytes(2^64 QB) prints "0.0 QB", and BigIBytes(2^164) prints "0.0 QiB". Convert the quotient through big.Float instead, which rounds the same way as float64(int64) for values that fit, so nothing below the boundary changes (inputs past the float64 range now come out as "+Inf QB" rather than an arbitrary 19-digit number). Added TestBigBytesBeyondInt64 with SI and IEC cases, which fails on master and passes with the change; go test -race ./..., go vet and gofmt are clean.