Thanks to each of you. Looks like we have a simple solution by just checking remaining, as suggested. I appreciate pointing out that it was a runtime error, so it definitely occurred and was not just a theoretical concern.
Thanks, Chris ________________________________ From: Hugh Parsonage <hugh.parson...@gmail.com> Sent: Thursday, March 23, 2023 7:17 AM To: Ivan Krylov <krylov.r...@gmail.com> Cc: Kenny, Christopher <christopherke...@fas.harvard.edu>; r-package-devel@r-project.org <r-package-devel@r-project.org> Subject: Re: [R-pkg-devel] How to identify what flags "Additional Issues" for UBSAN In line https://github.com/alarm-redist/redist/blob/f1ed042841469456c1d8c149092bc818e2a5c1a5/src/wilson.cpp#L165 int max_try = 50 * remaining * ((int) std::log(remaining)); you need to ensure remaining > 0. At some point it became -1. On Thu, 23 Mar 2023 at 22:07, Ivan Krylov <krylov.r...@gmail.com> wrote: > > � Wed, 22 Mar 2023 15:51:54 +0000 > "Kenny, Christopher" <christopherke...@fas.harvard.edu> �����: > > > Is there an easy way to identify what is causing the flag? > > Unfortunately, it's _all_ the sanitizer errors. > > > wilson.cpp:165:34: runtime error: signed integer overflow: > > -2147483648 * -1 cannot be represented in type 'int' > > > However, my understanding is that these errors should be expected, as > > the input is controlled from within the package and checking for > > these types of errors in every loop would push against the purpose of > > using C++ for performance here. > > You'd be right to think that signed integer overflow just wraps around > on modern CPUs with no adverse effects on the rest of the execution. > Unfortunately, you'd also need to convince the C++ optimiser, and it's > currently allowed to think otherwise. > > In C++, signed integer overflow (and other similar errors, such as > casing NaN to an integer) is undefined behaviour, which, according to > the standard, means that anything can happen after that, ranging from > nothing out of order to a crash and also to silent corruption of > important research results. Other languages define integer overflow to > have a more limited impact (wrap the value around or at least guarantee > a crash), but not C and C++. [*] > > Thankfully, I only see one spot where you encounter UB, in > src/wilson.cpp line 165, which should be relatively easy to fix by > adjusting your strategy for calculating the maximum number of tries. > (Do you get a NaN when `remaining` is -1? Why is it -1? Or is it 0?) > > -- > Best regards, > Ivan > > [*] > Some old gcc version used to launch the game Nethack when certain kinds > of UB were encountered. The situation has improved in some ways since > that and worsened in others: modern C and C++ compilers, especially > Clang, use UB to guide their optimisation efforts, so if the optimiser > can prove "if A is true then UB happens", it optimises with the > assumption that A is false. > > Combined with optimizer bugs, this understanding of undefined > behaviour may lead to funny situations where the inability of the > compiler to prove certain facts about the program leads to > mathematically inconsistent results: > https://blog.regehr.org/archives/140 > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel [[alternative HTML version deleted]]
______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
