This is the reason the package got kicked off CRAN.
On 2020-02-12 14:28, ligges@statistik.tu-dortmund.de wrote:
Dear maintainer,
package bikedata_0.2.5.tar.gz has been auto-processed and is pending a
manual inspection. A CRAN team member will typically respond to you
within the next 5 working days. For technical reasons you may receive
a second copy of this message when a team member triggers a new check.
We still see
bikedata.Rcheck/bikedata-Ex.Rout:utils.cpp:272:29: runtime error: signed
integer overflow: 702947 86400 cannot be represented in type 'int'
bikedata.Rcheck/bikedata-Ex.Rout:utils.cpp:273:24: runtime error: signed
integer overflow: 702947 86400 cannot be represented in type 'int'
Return values of d1 and d2 had already been modified to long int, which should have fixed it, but the interesting thing that i learnt was that the line
https://github.com/ropensci/bikedata/blob/6712945ebfcefcc8e6ab1755738499329da32519/src/utils.cpp#L272
has to (of course, obviously now and all ...) first construct a variable from y1 * 3600 * 24, where y1 is declared as <int>, so this is also first constructed as an <int>prior to ultimately being typecast as <long int>. It is this intermediate, implicit conversion that caused the issues. Now fixed by setting all as <long int>, with this issue serving as a record of this little quirk.
This is the reason the package got kicked off CRAN.
Those lines were these: https://github.com/ropensci/bikedata/blob/6712945ebfcefcc8e6ab1755738499329da32519/src/utils.cpp#L271-L273
Return values of
d1andd2had already been modified tolong int, which should have fixed it, but the interesting thing that i learnt was that the line https://github.com/ropensci/bikedata/blob/6712945ebfcefcc8e6ab1755738499329da32519/src/utils.cpp#L272 has to (of course, obviously now and all ...) first construct a variable fromy1 * 3600 * 24, wherey1is declared as<int>, so this is also first constructed as an<int>prior to ultimately being typecast as<long int>. It is this intermediate, implicit conversion that caused the issues. Now fixed by setting all as<long int>, with this issue serving as a record of this little quirk.