[hotfix] Fixed an issue where overflow from Long to Int was unsafe#1618
[hotfix] Fixed an issue where overflow from Long to Int was unsafe#1618XuQianJin-Stars wants to merge 1 commit into
Conversation
80f411d to
ca27fe9
Compare
| if (v instanceof Long) { | ||
| // TIMESTAMP | ||
| v2 = (int) (((Long) v) / TimeUnit.DAY.multiplier.longValue()); | ||
| v2 = Math.toIntExact(((Long) v) / TimeUnit.DAY.multiplier.longValue()); |
There was a problem hiding this comment.
One think I don't understand here is v2 is still used as long in the following code DateTimeUtils.unixDateExtract(timeUnitRange, v2);. Maybe the right fix is do not do long -> int conversion?
There was a problem hiding this comment.
One think I don't understand here is
v2is still used aslongin the following codeDateTimeUtils.unixDateExtract(timeUnitRange, v2);. Maybe the right fix is do not do long -> int conversion?
v2 = (Integer) v; should we cast to long too? If it was you would have to handle the int and long cases separately for DateTimeUtils.unixDateExtract (timeUnitRange, v2);
There was a problem hiding this comment.
Why do you think an integer days would overflow ? Can you give a test case ?
There was a problem hiding this comment.
Based on math, if you use max_long / milliseoncd_per_day, the number will still exceed int_max. So technically overflow exists.
There was a problem hiding this comment.
What is the upper/max value of timestamp million-seconds ?
49cb002 to
8768a23
Compare
8a5cf83 to
cf7f71b
Compare
3 participants
Fixed an issue where overflow from Long to Int was unsafe.