On 13/09/2019 10:15 a.m., Cristiane Hayumi Taniguti wrote:
I'm having difficulties updating my package onemap: When I run standard
checks as --as-cran in linux, winbuilder and using docker images everything
is fine, but 'CRAN-submissions' reports this problem in my c++ code:
onemap.Rcheck/onemap-Ex.Rout:
.............../usr/local/bin/../include/c++/v1/memory:1825:35: runtime
error: nan is outside the range of representable values of type 'int'
onemap.Rcheck/onemap-Ex.Rout:twopts_out.cpp:147:7: runtime error: nan is
outside the range of representable values of type 'int'
onemap.Rcheck/onemap-Ex.Rout:twopts_out.cpp:147:26: runtime error: nan
is outside the range of representable values of type 'int'
onemap.Rcheck/onemap-Ex.Rout:
...........................twopts_f2.cpp:101:7: runtime error: nan is
outside the range of representable values of type 'int'
onemap.Rcheck/onemap-Ex.Rout:twopts_f2.cpp:101:26: runtime error: nan is
outside the range of representable values of type 'int'
This problem was there in the last CRAN version of my package too <
https://www.stats.ox.ac.uk/pub/bdr/memtests/clang-UBSAN/onemap>
I am having a hard time trying to reproduce this error "at home" and fix
the problem. Without reproduce this I am not able to find what is causing
the nan in my code.
Here <https://drive.google.com/open?id=1L9Qcz9qraZOo-jaq-fwkF-PQfmg73mSv> is
the new version source package
I would add some kind of Rprintf statement near line 101 of
twopts_f2.cpp to show the value that you are apparently trying to coerce
to int at that point. Apparently it is sometimes equal to NaN, and this
is being caught in the CRAN checks, but not in yours. That might be
because they are doing more stringent checks (UBSAN is very stringent),
or it might be that the value is actually different on their system.
Duncan Murdoch
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
