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

fix Is the CString need to be freed? #10 #20

Merged
merged 1 commit into from
Jun 1, 2024
Merged

Conversation

CGMossa
Copy link
Contributor

@CGMossa CGMossa commented Jun 1, 2024

Fixes #10

We have been up and down, and everywhere with this issue.
This PR contains how it really ought to be done. Note that the documentation for std::mem::forget even recommends this approach.

@jeroen jeroen merged commit 2472f65 into r-rust:master Jun 1, 2024
5 checks passed
@jeroen
Copy link
Member

jeroen commented Jun 1, 2024

Thanks! So much cleaner.

@yutannihilation
Copy link
Contributor

Thanks! Let me clarify. Does this mean the answer to my question "Is the CString need to be freed?" is "No"?

@CGMossa
Copy link
Contributor Author

CGMossa commented Jun 2, 2024

Thanks! Let me clarify. Does this mean the answer to my question "Is the CString need to be freed?" is "No"?

I was worried about the validity of the returned pointer. Now that I'm looking at the r-source, I'm starting to worry, that yes, one has to free the resulting CString after the SEXP is created.

@yutannihilation
Copy link
Contributor

Yeah, obviously, it's not what R can free because it's not allocated by R. So, hellorust decided to let it leak instead of worrying about it, right? I think it's also reasonable.

@CGMossa
Copy link
Contributor Author

CGMossa commented Jun 2, 2024

I'll make another PR.

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 this pull request may close these issues.

Is the CString need to be freed?
3 participants