R devel - Apr 2017 - potential bug in attribute handling for externalptr

Is the following expected behavior?

 > mkext <- inline::cfunction(language="C", body='return 
R_MakeExternalPtr(NULL, install("tag"), R_NilValue);')
 > x <- mkext()
 > y <- x
 > attr(y, "foo") <- "bar"
 > attributes(x)
$foo
[1] "bar"

I would expect that modifying y's attributes should not affect x.

[Tested on R version 3.3.3 x86_64-apple-darwin16.4.0 (64-bit)]

Thanks,


Patrick

On Fri, Apr 14, 2017 at 11:27 PM, Patrick Perry <pperry at stern.nyu.edu>
wrote:
> Is the following expected behavior? I would expect that modifying y's
attributes should not affect x.
Yes this is expected. Environments and external-ptr objects are never
copied on assignment, hence in your example 'x' and 'y' are the
same
object. See e.g. ?reg.finalizer or section 5.13 of "writing r
extensions" on external pointers and weak references.

This is expected behaviour, pointers are an uncopyable type, just like
environments:

env <- new.env()
env
#> <environment: 0x7fb6d4822e30>

structure(env, foo = "bar")
env
#> <environment: 0x7fb6d4822e30>
#> attr(,"foo")
#> [1] "bar"


On Fri, Apr 14, 2017 at 11:27 PM, Patrick Perry <pperry at stern.nyu.edu>
wrote:
> Is the following expected behavior?
>
> > mkext <- inline::cfunction(language="C", body='return
> R_MakeExternalPtr(NULL, install("tag"), R_NilValue);')
> > x <- mkext()
> > y <- x
> > attr(y, "foo") <- "bar"
> > attributes(x)
> $foo
> [1] "bar"
>
> I would expect that modifying y's attributes should not affect x.
>
> [Tested on R version 3.3.3 x86_64-apple-darwin16.4.0 (64-bit)]
>
> Thanks,
>
>
> Patrick
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
	[[alternative HTML version deleted]]