Is 'JS_DupAtomRT' intentionally not exposed in quickjs.h?

[nathanvoglsam]

The public header exposes a 'JS_FreeAtomRT' function, but no 'JS_DupAtomRT'. However 'JS_DupAtomRT' does exist, it's just not exposed by the header.

The implementation of 'JS_DupAtom' and 'JS_DupAtomRT' is identical except for the extra pointer chase to get the runtime from the context as far as I can tell.

I'm using quickjs-ng from Rust, using my own opinionated set of bindings. My bindings make the choice to only allow a single runtime per thread using a thread local. This has the benefit of allowing me to use JSValue and JSAtom's refcount semantics without bundling a reference to the context/runtime with every JSValue in my Rust wrapper. I pin the version of quickjs and always build it myself, so at the moment I'm just calling 'JS_DupAtomRT' anyway. I'm not expecting any stability guarantees from a function not in the header, but it does work for now.

Is this an intentional choice? Would it be problematic to expose this in the header?

[bnoordhuis]

No particular reason.

For shared library builds it's slightly less efficient because exported symbols can be interposed, prohibiting the compiler from inlining them freely, but here that doesn't really matter because JS_DupAtomRT is only used in two places inside quickjs.c. And if it was a problem, we could always add a non-externally visible version.

I've opened #1258 - edit: and merged it.