[R-pkg-devel] CRAN and packages bundling third party C/C++ code

Kevin Ushey kevinushey at gmail.com
Thu Jan 18 20:19:12 CET 2018


This is mostly a question for the CRAN team, but I figured posting here
would be best since other package maintainers could see the responses as

I'm currently in the process of preparing a submission of RcppParallel to
CRAN. RcppParallel bundles Intel's Threading Building Blocks (https://www.
threadingbuildingblocks.org/) and builds + installs it alongside the

However, the TBB sources themselves do a lot of things that trip up R CMD
check + versions of R compiled with sanitizers, which are mostly out of my
control. For example, some UBSAN errors are emitted here:


Executing test function test.distance  ... /data/gannet/ripley/R/
runtime error: member call on address 0x7fbf31e93d00 which does not point
to an object of type 'tbb::internal::scheduler'
0x7fbf31e93d00: note: object is of type 'tbb::internal::custom_
 00 00 00 00  a8 ab 76 32 bf 7f 00 00  00 00 00 00 00 00 00 00  00 00 00 00
00 00 00 00  80 ff c9 31
              vptr for 'tbb::internal::custom_scheduler<tbb::internal::
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
RcppParallel/include/tbb/task.h:721:30 in

This occurs, as far as I can tell, because TBB sidesteps typical C++ object
construction for some objects: instead, it allocates some memory, then
casts it to some required type. As an example,


While this is 'wrong', it also 'works'. What am I, as a package maintainer,
supposed to do in this situation? To make things worse, this UBSAN warning
unfortunately affects all client packages of RcppParallel as well, as this
warning is triggered by code ran by RcppParallel on load / startup. Do
other package maintainers just need to say, "sorry, that's RcppParallel's

In addition, TBB itself suppresses a number of compiler diagnostics
deliberately -- for example,



Presumedly, TBB does this because they know what they're doing and the
compiler diagnostic will not be useful within this region of code. However,
this also triggers R CMD check warnings. What should I do here -- just
explain the case to CRAN? Patch TBB to allow the compiler diagnostics to
flow through?

The more general question here -- what should package authors do when
third-party code bundled in the package emits compiler warnings?


	[[alternative HTML version deleted]]

More information about the R-package-devel mailing list