Sorry to ask about a bit drifted topic, but will there be an alternative
API to DATAPTR?
> DATAPTR is not in the API and can't be at least in this form
I believe it's vital for ALTREP to return the pointer to the expanded
version of a SEXP just like the implementation in base R does [1].
At least
Thanks so much for your wonderful work, Luke!
I didn't expect such a clarification to happen this soon. This is really
great.
For convenience, I created a quick web page to search the result of
tools:::funAPI().
https://yutannihilation.github.io/R-fun-API/
Hope this helps those who are too lazy
On Sat, 8 Jun 2024, Ben Bolker wrote:
The ASAN errors occur *even if the zero-length object is not actually
accessed*/is used in a perfectly correct manner, i.e. it's perfectly legal in
base R to define `m <- numeric(0)` or `m <- matrix(nrow = 0, ncol = 0)`,
whereas doing the equivalent in Rc
The ASAN errors occur *even if the zero-length object is not actually
accessed*/is used in a perfectly correct manner, i.e. it's perfectly
legal in base R to define `m <- numeric(0)` or `m <- matrix(nrow = 0,
ncol = 0)`, whereas doing the equivalent in Rcpp will (now) lead to an
ASAN error.
IMHO, this should be changed in both Rcpp and downstream packages:
1. Rcpp could check for out-of-bounds accesses in cases like these, and
emit an R warning / error when such an access is detected;
2. The downstream packages unintentionally making these out-of-bounds
accesses should be fixed to a
A change to R-devel (SVN r86629 or
https://github.com/r-devel/r-svn/commit/92c1d5de23c93576f55062e26d446feface07250
has changed the handling of pointers to zero-length objects, leading to
ASAN issues with a number of Rcpp-based packages (the commit message
reads, in part, "Also define STR
