From p.dalgaard at biostat.ku.dk  Wed Jan 16 22:31:39 2008
From: p.dalgaard at biostat.ku.dk (Peter Dalgaard)
Date: Wed, 16 Jan 2008 22:31:39 +0100
Subject: [Rd] Pb with defineVar() example in the "Writing R Extensions"
 manual
In-Reply-To: <478E54D6.5040301@fhcrc.org>
References: <478D549E.40406@fhcrc.org> <478DD547.5080608@biostat.ku.dk>
	<478E4577.8040402@fhcrc.org> <478E48CD.3000602@biostat.ku.dk>
	<478E54D6.5040301@fhcrc.org>
Message-ID: <478E77BB.3040400@biostat.ku.dk>

Herve Pages wrote:
> Peter Dalgaard wrote:
>>
>> That's not the problem you raised (argument evaluation order), but
>> there's a CONS inside defineVar, and as far as I can see, it doesn't
>> protect its arguments, so you could well be right.
>>     
>
> This problem is related to my original problem since it would cause the same
> disaster: garbage collection on my unprotected SEXP.
>   
Sure, I just wasn't looking there because you told me to look elsewhere....

> The more general problem I'm facing is to know whether or not it is safe to
> use a function like mkans() (that returns an unprotected SEXP) like this:
>
>   SET_ELEMENT(ans, 0, mkans(x));
>
> In the case of SET_ELEMENT() or SET_STRING_ELT() it seems to be safe. For
> example I've seen this
>
>   SET_STRING_ELT(ans, 0, mkChar(buf));
>
> in many places. So I'm using it too, even if the SEXP returned by mkChar()
> is not protected.
> Same here:
>
>   SET_ELEMENT(ans, 0, duplicate(x));
>
> The SEXP returned by duplicate() is not protected.
>
> So everybody seems to assume that SET_ELEMENT(), SET_STRING_ELT(),
> SET_NAMES(), etc... can't (and will never) trigger garbage collection.
> But what about defineVar()? More generally, how do I know this for the
> functions/macros listed in Rdefines.h and Rinternals.h?
>   
>
Yes, that point was well taken. You can't know unless we write it 
somewhere. You can read the sources, but that is no guarantee that it 
won't change in future versions. We should be better at documenting that 
stuff, if for no other reason then to be able to distinguish between 
YOUR bugs and OUR bugs. 

If you grep through the sources, you'll find a number of instances of 
things like

defineVar(name, mkPromise(...), ...)

which would break along with your case, but that is of course only an 
indication, not proof that you can actually leave the value unprotected.

-- 
   O__  ---- Peter Dalgaard             ?ster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)                  FAX: (+45) 35327907



[Rd] Pb with defineVar() example in the "Writing R Extensions" manual
Peter Dalgaard