Use of C++ in Packages

Some of us are learning about development in R and use R in our work 
data analysis pipelines. What is the best way to identify packages 
that currently have these C++ problems? I would like to be able to 
help fix the bugs but more importantly not use these packages in 
critical work pipelines. Any C++ R package bug squashing events out there?

Regards

Hugh

On Mon, Apr 1, 2019 at 6:23 PM Tomas Kalibera 
<tomas.kalibera at gmail.com <mailto:tomas.kalibera at gmail.com>> wrote:

    On 3/30/19 8:59 AM, Romain Francois wrote:

    > tl;dr: we need better C++ tools and documentation.
    >
    > We collectively know more now with the rise of tools like rchk

    and improved documentation such as Tomas?s post. That?s a start,
    but it appears that there still is a lot of knowledge that would
    deserve to be promoted to actual documentation of best practices.
    Well there is quite a bit of knowledge in Writing R Extensions and
    many
    problems could have been prevented had it been read more
    thoroughly by
    package developers. The problem that C++ runs some functions
    automatically (like destructors), should not be too hard to identify
    based on what WRE says about the need for protection against garbage
    collection.

    ?From my experience, one can learn most about R internals from
    debugging
    and reading source code - when debugging PROTECT errors and other
    memory
    errors/memory corruption, common problems caused by bugs in native
    C/C++
    code - one needs to read and understand source code involved at all
    layers, one needs to understand the documentation covering code at
    different layers, and one has to think about these things, forming
    hypotheses, narrowing down to smaller examples, etc.

    My suggestion for package authors who write native code and want to
    learn more, and who want to be responsible (these kinds of bugs
    affect
    other packaged indirectly and can be woken up by inconsequential and
    correct code changes, even in R runtime): test and debug your code
    hard
    - look at UBSAN/ASAN/valgrind/rchk checks from CRAN and run these
    tools
    yourself if needed. Run with strict barrier checking and with
    gctorture.
    Write more tests to increase the coverage. Specifically now if you
    use
    C++ code, try to read all of your related code and check you do
    not have
    the problems I mentioned in my blog. Think of other related
    problems and
    if you find about them, tell others. Make sure you only use the
    API from
    Writing R Extensions (and R help system). If you really can't find
    anything wrong about your package, but still want to learn more,
    try to
    debug some bugs reported against R runtime or against your favorite
    packages you use (or their CRAN check reports from various tools). In
    addition to learning more about R internals, by spending much more
    time
    on debugging you may also get a different perspective on some of the
    things about C++ I pointed to. Finally, it would help us with the
    problem we have now - that many R packages in C++ have serious bugs.

    Tomas