-
Notifications
You must be signed in to change notification settings - Fork 997
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
fix bit64 coercion in memrecycle #5835
Conversation
No need NEWS info. It's was just a warning, behavior is not really changed. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #5835 +/- ##
=======================================
Coverage 97.46% 97.46%
=======================================
Files 80 80
Lines 14822 14822
=======================================
Hits 14447 14447
Misses 375 375 ☔ View full report in Codecov by Sentry. |
any idea if bit64 integer64 type can handle 64bit or 53bit of data? If it is based on R's double then probably only 53bit. Then testing |
According to documentation and implementation they can handle [-2^63+2, 2^63-1] which makes sense, since -2^63+1 (LLONG_MIN) represents NA_INTEGER64 |
hi @ben-schwen thanks for the PR. Please consider volunteering as a reviewer for assign.c (add a line to CODEOWNERS, nobody has volunteered for that file yet). |
I propose that this PR be now merged so that my PR (which will conflict) can be finalized. |
nit about dropping |
Co-authored-by: Michael Chirico <chiricom@google.com>
Co-authored-by: Michael Chirico <chiricom@google.com>
Closes #5834
Follow up to #5189
Type coercion is from double[numeric] into double[integer64].
Previously we checked
int(val)!=val
for detecting truncation.Since integer64 can handle much longer values the correct check is
(int64_t)val!=val
.Alters two tests since no truncation/precision loss takes place.
@jangorecki does this need a NEWS item?