Skip to content

Fix GetString precision loss for large int64 values#150

Merged
pimbrouwers merged 1 commit intofalcoframework:masterfrom
michaelglass:fix/issue-149-large-int-precision
Feb 6, 2026
Merged

Fix GetString precision loss for large int64 values#150
pimbrouwers merged 1 commit intofalcoframework:masterfrom
michaelglass:fix/issue-149-large-int-precision

Conversation

@michaelglass
Copy link
Contributor

@michaelglass michaelglass commented Feb 2, 2026

Summary

Problem

GetString was converting large integer route values (like Int64.MaxValue) to scientific notation, causing precision loss:

ctx.Request.RouteValues.Add("id", "9223372036854775807")  // Int64.MaxValue
let route = Request.getRoute ctx
route.GetString "id"  // Was: "9.223372036854776E+18", Now: "9223372036854775807"

Root Cause

The IsFloat pattern was parsing all numeric-looking strings as float64 values. For integers with more than ~15 significant digits, this caused precision loss since float64 only has 15-16 digits of precision.

Solution

Modified the IsFloat pattern to not match integer strings with more than 15 significant digits. Such values now remain as RString, preserving the original value exactly.

This doesn't break GetInt64 because it already handles RString values by parsing them directly via StringParser.parseInt64.

Test plan

  • Added unit tests for precision boundary (15 vs 16+ digit integers)
  • Added regression test for route values with Int64.MaxValue
  • All 71 existing tests pass

🤖 Generated with Claude Code.

I (the human, Michael) couldn't find any place in the contribution docs that was against this, I hope it's ok. (also: want to be transparent about our slow demise as working software devs)

Prevent integers with more than 15 significant digits from being parsed
as floats, which would lose precision. Such values now remain as strings,
preserving the original value while still allowing GetInt64 to parse them
correctly.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@pimbrouwers
Copy link
Member

Really nice to meet you Michael. Thank you very much for this excellent contribution. I really appreciate it. I am very happy to merge this and will definitely do so to mark the contribution. It also points to something broader.

Reviewing my work here with fresh eyes and more experience. I'm not pleased with the test coverage, I don't even need to run code coverage to know it's subpar. For example, the string utilities should be directly tested despite being part of the non-public API.

I am going to change this in short order and I mention it partly because in the next little while, the surface of your contribution may change. But the essence will be there, and I didn't want there to be any animus. Does that make sense?

@pimbrouwers pimbrouwers merged commit 32e9740 into falcoframework:master Feb 6, 2026
1 check 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