Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

avoid using EXTPTR_PTR #1097

Closed
kevinushey opened this issue Jun 29, 2020 · 4 comments · Fixed by #1098
Closed

avoid using EXTPTR_PTR #1097

kevinushey opened this issue Jun 29, 2020 · 4 comments · Fixed by #1098

Comments

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Jun 29, 2020

As it's not part of the official R API. See https://r.789695.n4.nabble.com/Possible-ABI-change-in-R-4-0-1-td4764335.html for details.

We should use R_ExternalPtrAddtr() instead.

kevinushey@cdrv:~/r/pkg/Rcpp [master]
$ rg "EXTPTR_PTR"
inst/include/Rcpp/module/class.h
170:                vec_signed_method* mets = reinterpret_cast< vec_signed_method* >( EXTPTR_PTR( method_xp ) ) ;
197:                vec_signed_method* mets = reinterpret_cast< vec_signed_method* >( EXTPTR_PTR( method_xp ) ) ;
219:                vec_signed_method* mets = reinterpret_cast< vec_signed_method* >( EXTPTR_PTR( method_xp ) ) ;
396:                prop_class* prop = reinterpret_cast< prop_class* >( EXTPTR_PTR( field_xp ) ) ;
403:                prop_class* prop = reinterpret_cast< prop_class* >( EXTPTR_PTR( field_xp ) ) ;

src/api.cpp
148:    snprintf(buffer, 20, "%p", (void*)EXTPTR_PTR(xp));

src/module.cpp
56:    return EXTPTR_PTR(xp) == 0;

Evidently this change was done way back in 2011 as well for some usages:

Rcpp/ChangeLog

Lines 6630 to 6634 in b125470

2011-02-10 Douglas Bates <bates@stat.wisc.edu>
* inst/include/Rcpp/XPtr.h: Replace calls to EXTPTR_PTR with
R_ExternalPtrAddr. The distinction is important when R is
compiled with PROTECTCHECK enabled.

@eddelbuettel
Copy link
Member

@eddelbuettel eddelbuettel commented Jun 29, 2020

Sure, good catch. Saw that discussion, and of course the ping-pong between @gaborcsardi and myself about the roxygen2 issue he was pinning on us which I didn't want to have here ... til @jeroen found this underlying change.

Which, almost surely, is not related to the roxygen2 issue as the above (which I also see here using ag rather than rg) affects only Modules which "some" package use, but not many -- and almost surely not roxygen2.

Let me chew over if I want to tackle this this week or rather ship what we have now as 1.0.5 and then let a change such as this "rest and mature" a little en route to 1.0.6. If that release happens. Because I am still not over the nonsense I had to put up with in the discussion after 1.0.4 came out, and we had risked late changes. Very little appetite for repeating that....

@eddelbuettel
Copy link
Member

@eddelbuettel eddelbuettel commented Jun 29, 2020

I mistook the reference from src/api.cpp for something else at first. That is a pretty-printer, rather than the package status, so that could indeed be called more widely.

@eddelbuettel
Copy link
Member

@eddelbuettel eddelbuettel commented Jun 29, 2020

By the same token this and the code below in the same file may need a rethink:

#define USE_RINTERNALS

@eddelbuettel
Copy link
Member

@eddelbuettel eddelbuettel commented Jun 30, 2020

Hm, and R_ExternalPtrAddr() is from R_Internals.h, which is not part of the API. There is a reference to Chap 6 of WRE but that does clarify too much either.

Ok, it is in the 'else' branch of #ifdef USE_RINTERNALS so that;s clearer. False alarm by me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants