R devel - Apr 2006 - protection needed?

Dear list,

I am unsure if I really need to protect a coerced object if I
immediately access its value and don't access the object anymore. I
tried to find out by looking into the R sources but didn't find
something similar.

It's about the variable _skipLines in the call "function ReadXls(
_file, _sheet, _type, _header, _colHeader, _skipLines: pSExp ): pSExp;
cdecl;".

I did:
    skipLines:= riInteger( riCoerceVector( _skipLines, setIntSxp ) )[0];

but am unsure if I would have to something along:
    skipInt:= riProtect( riCoerceVector( _skipLines, setIntSxp ) );
    skipLines:= riInteger( skipInt )[0];
    riUnprotect( 1 );

According to the manual the second is probably more appropriate but as
I found some places in the R sources where no protection was made, I
decided to ask. Thanks a lot !

--
Regards,
Hans-Peter

On Tue, 25 Apr 2006, Hans-Peter wrote:
> Dear list,
>
> I am unsure if I really need to protect a coerced object if I
> immediately access its value and don't access the object anymore. I
> tried to find out by looking into the R sources but didn't find
> something similar.
>
> It's about the variable _skipLines in the call "function ReadXls(
> _file, _sheet, _type, _header, _colHeader, _skipLines: pSExp ): pSExp;
> cdecl;".
>
> I did:
>    skipLines:= riInteger( riCoerceVector( _skipLines, setIntSxp ) )[0];
>
> but am unsure if I would have to something along:
>    skipInt:= riProtect( riCoerceVector( _skipLines, setIntSxp ) );
>    skipLines:= riInteger( skipInt )[0];
>    riUnprotect( 1 );
>
Well, assuming that I am guessing correctly about the code (?Pascal), 
either is ok.

You don't do anything to the output of riCoerceVector() that could cause 
garbage collection before you stop using it, so it doesn't need 
protection.

Now, this assumes that you know riInteger() doesn't garbage collect (and 
won't in the future). The former is definitely true and the latter is a 
reasonably safe bet.

There is a paragraph in Writing R Extensions section 5.7.1 that advises 
extreme caution when making this kind of assumption. That's because 
it's easy to overlook problems, things might change, and it can be really 
painful to track down pointer protection bugs.  It is usually prudent to 
code as if the garbage collector is out to get you, unless you are doing 
deep recursion or other types of coding where running out of pointer 
protection stack is a real concern.


 	-thomas

Thomas Lumley			Assoc. Professor, Biostatistics
tlumley at u.washington.edu	University of Washington, Seattle