- 
          
- 
                Notifications
    You must be signed in to change notification settings 
- Fork 652
fix: fix precision bug in parseFloat affecting select(DOUBLE) in prepared statements #1527
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.
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
base: master
Are you sure you want to change the base?
fix: fix precision bug in parseFloat affecting select(DOUBLE) in prepared statements #1527
Conversation
| @wellwelwel Exactly what kind of tests are you looking for, here? The current code is demonstrably wrong. Testing the implementation of parseFloat() is covered by the V8 team. | 
| 
 Hi, @wesgarland. As a fix, to effectively check and ensure that the bug does not recur, it's a useful practice, when possible, ensuring automated tests that reproduce the failure and wait for the failure if the proposed correction is not applied. This also helps to ensure that the correction actually fixes the proposed error. | 
| Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@            Coverage Diff             @@
##           master    #1527      +/-   ##
==========================================
+ Coverage   89.78%   89.83%   +0.05%     
==========================================
  Files          86       86              
  Lines       13607    13579      -28     
  Branches     1607     1600       -7     
==========================================
- Hits        12217    12199      -18     
+ Misses       1390     1380      -10     
 Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
 | 
| I forced the current tests to run through this PR. For me, just removing the variables that are no longer used after the fix is fine. I'm going to take a break to carefully read the discussion that led to this PR in #1525. | 
| @wellwelwel Thanks for picking this up and running with it. I don't think there was a CI pipeline when I patched this ~ 4 years ago or I would have picked up on the lint errors. Or maybe I just missed it... anyhow. To summarize "how we got here", I discovered that selecting float64 values from mysql would give different values in node in some circumstances. The reason is that in those circumstances, they are transmitted over the network as ASCII strings, and sidorares wrote his own implementation of parseFloat in JavaScript. This implementation was marginally faster than that the one built into V8 because it cheated, and made mistakes. My patch removes that code, and uses the parseFloat builtin. Parsing floating point numbers is a very tricky topic, and writing a test to ensure that a given parser does not make mistakes is a technically challenging task. I do think, however, that assuming that the JS engine implements it correctly is a reasonable assumption. In retrospect, I'm not sure why I chose to use parseFloat() instead of Number(). I should have documented. It's plausible that Number() would be a few nanoseconds faster. | 
| 
 I agree. If there were to be a method that competes with V8, I think a dedicated library would be more appropriate, since it is not so simple to test and cover all scenarios. | 
This corrects Issue #1525 by falling back to the JS engine's own implementation of parseFloat.