Hi Dirk,
Sure, let me try to explain:
CRAN ran the tests of my package using R which was configured
--with-valgrind-instrumentation > 0. Valgrind reported many errors related to
the use of supposedly uninitialized memory and the CRAN team asked me to tackle
these.
These errors are false posit
Andreas,
Can you briefly describe what it is you are trying to do?
In general, no R package would use valgrind directly; it is an optional
debugger. Also note _Writing R Extensions_ has a few things to say about how
memory destined for R object can and cannot be allocated -- I presume your
cust
Another idea for the second option. Instead of including the Valgrind headers,
the following could be enough:
#if __has_include()
#include
#else
#define VALGRIND_MAKE_MEM_DEFINED(_qzz_addr,_qzz_len) \
do { \
(_qzz_addr);
> Duncan Murdoch
> on Thu, 25 Mar 2021 10:41:46 -0400 writes:
> On 25/03/2021 9:18 a.m., Dirk Eddelbuettel wrote:
>>
>> On 24 March 2021 at 10:30, Martin Maechler wrote:
>> | For this reason I've committed to R (the trunk, i.e., R-devel,
>> | for R 4.1.0 in a mont
Hi,
In my package bettermc, I use a custom allocator, which hands out already
defined/initialized memory (mmap of a POSIX shared memory object).
If my code is run in R which was configured --with-valgrind-instrumentation >
0, Valgrind will (correctly) complain about uninitialized memory being u
