Ben,
yes, you have to store the result into a variable, then unprotect, then return.
Cheers,
S
> On 24/03/2020, at 10:07 AM, Ben Bolker <bbol...@gmail.com> wrote:
>
>
> Thanks, that's really useful. One more question for you, or someone
> else here:
>
> const ArrayXd glmLink::linkFun(const ArrayXd& mu) const {
> return as<ArrayXd>(::Rf_eval(::Rf_lang2(as<SEXP>(d_linkFun),
>
> as<SEXP>(Rcpp::NumericVector(mu.data(),
>
> mu.data() + mu.size()))
> ), d_rho);
> }
>
>
> I guess I need that to read
> PROTECT(::Rf_eval(PROTECT(::Rf_lang2(...),...) , but as written it
> doesn't seem I have anywhere to squeeze in an UNPROTECT(2). Do I need
> to define a temporary variable so I can UNPROTECT(2) before I return the
> value?
>
> Or is there a way I can use Shield() since this an Rcpp-based project
> anyway?
>
> Sorry for all the very basic questions, but I'm flying nearly blind
> here ...
>
> cheers
> Ben Bolker
>
>
>
> On 2020-03-23 4:01 p.m., Tomas Kalibera wrote:
>> On 3/23/20 8:39 PM, Ben Bolker wrote:
>>> Dear r-devel folks,
>>>
>>> [if this is more appropriate for r-pkg-devel please let me know and
>>> I'll repost it over there ...]
>>>
>>> I'm writing to ask for help with some R/C++ integration idioms that are
>>> used in a package I'm maintaining, that are unfamilar to me, and that
>>> are now being flagged as problematic by Tomas Kalibera's 'rchk'
>>> machinery (https://github.com/kalibera/rchk); results are here
>>> https://raw.githubusercontent.com/kalibera/cran-checks/master/rchk/results/lme4.out
>>>
>>>
>>> The problem is with constructions like
>>>
>>> ::Rf_eval(::Rf_lang2(fun, arg), d_rho)
>>>
>>> I *think* this means "construct a two-element pairlist from fun and arg,
>>> then evaluate it within expression d_rho"
>>>
>>> This leads to warnings like
>>>
>>> "calling allocating function Rf_eval with argument allocated using
>>> Rf_lang2"
>>>
>>> Is this a false positive or ... ? Can anyone help interpret this?
>> This is a true error. You need to protect the argument of eval() before
>> calling eval, otherwise eval() could destroy it before using it. This is
>> a common rule: whenever passing an argument to a function, that argument
>> must be protected (directly or indirectly). Rchk tries to be smart and
>> doesn't report a warning when it can be sure that in that particular
>> case, for that particular function, it is safe. This is easy to fix,
>> just protect the result of lang2() before the call and unprotect (some
>> time) after.
>>> Not sure why this idiom was used in the first place: speed? (e.g., see
>>> https://stat.ethz.ch/pipermail/r-devel/2019-June/078020.html ) Should I
>>> be rewriting to avoid Rf_eval entirely in favor of using a Function?
>>> (i.e., as commented in
>>> https://stackoverflow.com/questions/37845012/rcpp-function-slower-than-rf-eval
>>>
>>> : "Also, calling Rf_eval() directly from a C++ context is dangerous as R
>>> errors (ie, C longjmps) will bypass the destructors of C++ objects and
>>> leak memory / cause undefined behavior in general. Rcpp::Function tries
>>> to make sure that doesn't happen.")
>>
>> Yes, eval (as well as lang2) can throw an error, this error has to be
>> caught via R API and handled (e.g. by throwing as exception or something
>> else, indeed that exception then needs to be caught and possibly
>> converted back when leaving again to C stack frames). An R/C API you can
>> use here is R_UnwindProtect. This is of course a bit of a pain, and one
>> does not have to worry when programming in plain C.
>>
>> I suppose Rcpp provides some wrapper around R_UnwindProtect, that would
>> be a question for Rcpp experts/maintainers.
>>
>> Best
>> Tomas
>>
>>>
>>> Any tips, corrections, pointers to further documentation, etc. would be
>>> most welcome ... Web searching for this stuff hasn't gotten me very far,
>>> and it seems to be deeper than most of the introductory material I can
>>> find (including the Rcpp vignettes) ...
>>>
>>> cheers
>>> Ben Bolker
>>>
>>> ______________________________________________
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
