Rcpp aims at a six-months release cycle with releases in January and July, and has followed this pattern for a few years. The next release 1.0.13 is due next month, and with the ongoing changes in R(-devel) to more formally define the C API of R, we now merged a PR (#1310) prepared by Kevin to avoid the use of DATAPTR. (It also 'hardens' out of bounds access a little; the opt-out config variable that always existed is still there should you need it.)

The PR was tested diligently via nearly all 2800 reverse dependencies. It lead us to soften one stop() to a warning(). In the last run, four packages exhibited issues that are 'new relative to the CRAN version'. We recognise that we are imposing a small change on others, but we are doing so in the spirit of making R more solid using more well defined interfaces. We will that a change improving use and setup for over 2800 package is worth the small price of asking for a change in just four packages.

The packages in question, their relative versions. maintainers and repos are

• bayesianVARs (0.1.2) @luisgruber https://github.com/luisgruber/bayesianVARs -- passes with 0.1.3
• PKPDsim (1.3.0) @ronkeizer @roninsightrx https://github.com/InsightRX/PKPDsim
• reservr (0.0.2) @AshesITR https://github.com/AshesITR/reservr -- no longer an issue in 0.0.3 on CRAN as of 2024-06-24
• TreeDist (2.7.0) @ms609 https://github.com/ms609/TreeDist/ -- passes with rebuilt TreeTools

Maintainers (and of course everybody else) can access a release candidate for the upcoming Rcpp 1.0.13 in the current version from its repo¹, the rcpp drat², or r-universe³⁴.

I plan to follow-up in email too but encourage everybody to follow-up here (or on the rcpp-devel list, if you are subscribed already; else consider subscribing and 'lurking').

So if there are any questions, just ask.

PS As noted below, I prepared 1.0.12.4 and eg shipped to the drat repo but failed to then push here so r-universe was behind in it build. The Rcpp repo will have had the correct code merged but not at the right version. This should now be fine with 1.0.12.4 at sha1 5189611. The key merged was PR #1310 merged at 5614a8b so if you installed from source (eg via remotes) or from r-universe) within the last day or so after i opened this issue you will have gotten, it just did not yet call itself 1.0.12.4 as it does now. Sorry for any confusion on that.