From r|p|ey @end|ng |rom @t@t@@ox@@c@uk  Wed Mar  2 11:57:07 2022
From: r|p|ey @end|ng |rom @t@t@@ox@@c@uk (Prof Brian Ripley)
Date: Wed, 2 Mar 2022 10:57:07 +0000
Subject: [Rd] Making CRAN memory access checks more accessible?
In-Reply-To: <CAHqSRuTwOWmcqDXxy-JgFUFuoRg1PUP2BO=KQ37PPngPCqgZaw@mail.gmail.com>
References: <CAByPayEp5sVw1S6mC5Juec9vayGvAsE4V318vRzLLG9d72G0sg@mail.gmail.com>
 <CAHqSRuTwOWmcqDXxy-JgFUFuoRg1PUP2BO=KQ37PPngPCqgZaw@mail.gmail.com>
Message-ID: <f3d235c0-01a9-f920-2b2e-d85096369e7a@stats.ox.ac.uk>

On 28/02/2022 19:15, Bill Dunlap wrote:
> valgrind will detect some of the memory issues that UBSAN does.  

Only very few.  None of the current 43 CRAN packages with UBSAN issues 
have them detected by valgrind ... the valgrind overlap is more with 
ASAN issues (see 
https://github.com/google/sanitizers/wiki/AddressSanitizerComparisonOfMemoryTools).

The UB sanitizer is heavily tied to the compiler.  This has meant that 
new versions of gcc have found more and more issues and (most 
pertinently here) recent versions of clang find about twice as many 
issues as gcc 10/11.

UBSAN in theory runs on quite a range of platforms --- 
https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#supported-platforms 
-- which unfortunately does not say for which CPUs on those OS.  (Also, 
that is about LLVM clang and not Apple clang as normally used on macOS. 
  And gcc seems only to point to LLVM documentation for supported 
platforms, but its implementation clearly differs.)


-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford



[Rd] Making CRAN memory access checks more accessible?
Prof Brian Ripley