Skip to content

Remove jsonwire.ParseFloat fast path #139

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 21, 2025
Merged

Remove jsonwire.ParseFloat fast path #139

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 0 additions & 13 deletions internal/jsonwire/decode.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -610,19 +610,6 @@ func ParseUint(b []byte) (v uint64, ok bool) {
// then we return MaxFloat since any finite value will always be infinitely
// more accurate at representing another finite value than an infinite value.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment still stands as a valid argument. This is especially more relevant in v2 since we do provide opt-in support for actual infinity.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, reverted most changes.

we do provide opt-in support for actual infinity

Sorry, but I don't understand this. I see the only option related to overflow is removed at #130 .

I don't want this behavior because (almost) all others just return infinity, including Go strconv. I think they have good reason for that. For example, if I get this json:

{
    "total": 1e1000
    "used": 1e500
}

I definitely don't want total - used to be 0. Infinite value is inaccurate, but it records the inaccuracy, e.g. "1e1000 - 1e500" should be NaN.

And for Token.Float(), we don't return error, so we even can't know we got overflow.

But we can defer this discussing to another PR.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing out that example.

Unfortunately, I don't believe there are any good answers here.

With regard to Javascript and Python. While they are both consistent with each other in that they parse 1e1000 as Infinity without error, they are inconsistent with round trip serialization:

  • JavaScript: JSON.stringify(JSON.parse("1e1000")) returns null.
  • Python: json.dumps(json.loads("1e1000")) returns Infinity (which isn't even valid JSON).

Neither of them report an error and also inconsistent with each other for roundtrip serialization. In my opinion, this is the worst position to take since it leads to silent data loss.

In Go, we have decided that a float overflow is an error. This is arguably the most significant divergence from JS and Python, and whether we still return Inf and or MaxFloat is a minor detail.

  • The reason for using max float is to ensure the JSON kind does not abruptly change due to a round trip. Thus, unmarshaling 1e1000 and marshaling it should still resulting a JSON number (e.g., 1.7976931348623157e+308), not a JSON string (e.g., "Inf").
  • I can see how total - use becoming 0 could be a bug, but I should note that we are still reporting a Go error for the overflow. Thus, in order for this to be a logical bug, it would have to be after an error that was ignored.

func ParseFloat(b []byte, bits int) (v float64, ok bool) {
// Fast path for exact integer numbers which fit in the
// 24-bit or 53-bit significand of a float32 or float64.
var negLen int // either 0 or 1
if len(b) > 0 && b[0] == '-' {
negLen = 1
}
u, ok := ParseUint(b[negLen:])
if ok && ((bits == 32 && u <= 1<<24) || (bits == 64 && u <= 1<<53)) {
return math.Copysign(float64(u), float64(-1*negLen)), true
}

// Note that the []byte->string conversion unfortunately allocates.
// See https://go.dev/issue/42429 for more information.
fv, err := strconv.ParseFloat(string(b), bits)
if math.IsInf(fv, 0) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's keep this behavior.

switch {
Expand Down
Loading