[Rd] Usage of PROTECT_WITH_INDEX in R-exts
maechler at stat.math.ethz.ch
Fri Jun 9 13:23:07 CEST 2017
>>>>> Kirill Müller <kirill.mueller at ivt.baug.ethz.ch>
>>>>> on Thu, 8 Jun 2017 12:55:26 +0200 writes:
> On 06.06.2017 22:14, Kirill Müller wrote:
>> On 06.06.2017 10:07, Martin Maechler wrote:
>>>>>>>> Kirill Müller <kirill.mueller at ivt.baug.ethz.ch> on
>>>>>>>> Mon, 5 Jun 2017 17:30:20 +0200 writes:
>>> > Hi I've noted a minor inconsistency in the
>>> documentation: > Current R-exts reads
>>> > s = PROTECT_WITH_INDEX(eval(OS->R_fcall, OS->R_env),
>>> > but I believe it has to be
>>> > PROTECT_WITH_INDEX(s = eval(OS->R_fcall, OS->R_env),
>>> > because PROTECT_WITH_INDEX() returns void.
>>> Yes indeed, thank you Kirill!
>>> note that the same is true for its partner
>>> function|macro REPROTECT()
>>> However, as PROTECT() is used a gazillion times and
>>> PROTECT_WITH_INDEX() is used about 100 x less, and
>>> PROTECT() *does* return the SEXP, I do wonder why
>>> PROTECT_WITH_INDEX() and REPROTECT() could not behave
>>> the same as PROTECT() (a view at the source code seems
>>> to suggest a change to be trivial). I assume usual
>>> compiler optimization would not create less efficient
>>> code in case the idiom PROTECT_WITH_INDEX(s = ...) is
>>> used, i.e., in case the return value is not used ?
>>> Maybe this is mainly a matter of taste, but I find the
>>> use of
>>> SEXP s = PROTECT(........);
>>> quite nice in typical cases where this appears early in
>>> a function. Also for that reason -- but even more for
>>> consistency -- it would also be nice if
>>> PROTECT_WITH_INDEX() behaved the same.
>> Thanks, Martin, this sounds reasonable. I've put together
>> a patch for review , a diff for applying to SVN (via
>> `cat | patch -p1`) would be . The code compiles on my
>>  https://github.com/krlmlr/r-source/pull/5/files
> I forgot to mention that this patch applies cleanly to r72768.
Thank you, Kirill.
I've been a bit busy so did not get to reply more quickly.
Just to be clear: I did not ask for a patch but was _asking_ /
requesting comments about the possibility to do that.
In the mean time, within the core team, the opinions were
mixed and costs of the change (recompilations needed, C source level
check tools would need updating / depend on R versions) are
As a consquence, we will fix the documentation, rather than changing the API.
More information about the R-devel