[Rd] changes in R-devel and zero-extent objects in Rcpp

[Kevin Ushey]

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 avoid doing that.

That is, I think this is ultimately a bug in the affected packages, but
Rcpp could do better in detecting and handling this for client packages
(avoiding a segfault).

Best,
Kevin


On Sat, Jun 8, 2024, 3:06 PM Ben Bolker <bbolker using gmail.com> wrote:

>
>     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 STRICT_TYPECHECK when compiling inlined.c.")
>
>    I'm interested in discussion from the community.
>
>    Details/diagnosis for the issues in the lme4 package are here:
> https://github.com/lme4/lme4/issues/794, with a bit more discussion
> about how zero-length objects should be handled.
>
>    The short(ish) version is that r86629 enables the
> CATCH_ZERO_LENGTH_ACCESS definition. This turns on the CHKZLN macro
> <
> https://github.com/r-devel/r-svn/blob/4ef83b9dc3c6874e774195d329cbb6c11a71c414/src/main/memory.c#L4090-L4104>,
>
> which returns a trivial pointer (rather than the data pointer that would
> be returned in the normal control flow) if an object has length 0:
>
> /* Attempts to read or write elements of a zero length vector will
>     result in a segfault, rather than read and write random memory.
>     Returning NULL would be more natural, but Matrix seems to assume
>     that even zero-length vectors have non-NULL data pointers, so
>     return (void *) 1 instead. Zero-length CHARSXP objects still have a
>     trailing zero byte so they are not handled. */
>
>    In the Rcpp context this leads to an inconsistency, where `REAL(x)`
> is a 'real' external pointer and `DATAPTR(x)` is 0x1, which in turn
> leads to ASAN warnings like
>
> runtime error: reference binding to misaligned address 0x000000000001
> for type 'const double', which requires 8 byte alignment
> 0x000000000001: note: pointer points here
>
>     I'm in over my head and hoping for insight into whether this problem
> should be resolved by changing R, Rcpp, or downstream Rcpp packages ...
>
>    cheers
>     Ben Bolker
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]