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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
