rchk MAKE_CLASS vulnerability

[rsbivand]

NEW_OBJECT(MAKE_CLASS()) does not PROTECT() the output of MAKE_CLASS(). In Matrix, there is

/**
 * A safe  NEW_OBJECT_OF_CLASS(cls),  where the caller must protect the
 * return value of this function
 *
 * @param an R character string specifying the name of a known S4 class
 */
SEXP NEW_OBJECT_OF_CLASS(const char* cls)
{
    SEXP ans = NEW_OBJECT(PROTECT(MAKE_CLASS(cls)));
    UNPROTECT(1);
    return ans;
}

but I chose to do it in the functions, incrementing the pc counter.

I guess that you do not have time to make an rchk container, but we need one quite urgently, to be able to see that works. The recipe is for Debian and Debian-based containers, which I would need to learn from near-zero. Is there any chance of trying this on sp, then on rgeos and rgdal because the sp issues spill over through LinkingTo:?

[edzer]

Thanks! Which checks do you in particular want to (have) run? This container mirrors Kurt's debian images in terms of sysreqs, is easy to set up and equip with valgrind, but still runs R 3.4.4.

[rsbivand]

Yes, that would be convenient, but rgck needs an instrumented build, from current devel. See if you think the description seems feasible - I think the increase in numbers of issues is because there is active work on the checks.

[rsbivand]

Follow-up PR with build-prep ...

[rsbivand]

rgeos and rgdal are out, revised, on CRAN, but dont't resolve the rchk issues (I think). I wrote to CRAN suggesting that the next step is to release sp with rchk fixes, then new releases of rgeos and rgdal with rchk fixes, including the rchk issues in rgeos and rgdal that will be resolved when the revised sp to which they link is released.

[edzer]

OK, shall I release sp? Or shall we do a revdeps first?

[rsbivand]

Please do revdeps; I have not done it, and it may save time if there are issues that the CRAN checks find.