From hugh@m@rer@ @end|ng |rom gm@||@com  Wed Apr 24 18:41:36 2019
From: hugh@m@rer@ @end|ng |rom gm@||@com (Hugh Marera)
Date: Wed, 24 Apr 2019 18:41:36 +0200
Subject: [Rd] Use of C++ in Packages
In-Reply-To: <b6fa43a9-335b-5cf2-b91a-40daf38e8cae@gmail.com>
References: <CAD6tx97B3zHikY9Cs+DnMXdOFFUn76ONoTupZT8QTaqo7+xZCA@mail.gmail.com>
 <DA086757-A81C-4E25-AE4D-2E4BCA187941@R-project.org>
 <CAJXgQP2OuQ98zzj-8CNSFVBTv4OU0tsA12HH++x=r4vpxi7Osw@mail.gmail.com>
 <F68C848D-AE93-4CA9-9314-1ACDB23B87F6@r-project.org>
 <5A14862F-729A-484C-A196-CA5F1D91B524@rstudio.com>
 <b6fa43a9-335b-5cf2-b91a-40daf38e8cae@gmail.com>
Message-ID: <CAGpovd1TeS9qHffPePAJHWnd9o_C-3geUB_KZAYUk84wEi3nRw@mail.gmail.com>

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

	[[alternative HTML version deleted]]



[Rd] Use of C++ in Packages
Hugh Marera