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

[Ben Bolker]

    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