Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello!
I've got a PR here for adding a new 'JS_FreeCStringRT' function that (if I understand the code correctly) should function the same as the existing 'JS_FreeCString' but takes a JSRuntime instead of a JSContext. It looks like the c-string being returned is just actually a JSString value with the string data trailing off the end of the allocation. I can't see any obvious reason why it needs to be tied to a JSContext.
My motivation for this feature follows on from my question in this discussion. My Rust bindings rely on a single, thread local JSRuntime for each thread. Nothing can get sent to other threads so I get a reasonably safe API without lifetime soup. The c-strings were the odd one left, still needing a reference to the JSContext they were created from so I could clean them up with RAII. With this change that can go away.
If this is API internals you don't want to commit to I understand, as this is a whole new API, but thought I'd forward this for discussion.
Seems to work in my Rust code but I haven't tested very thoroughly.