search

nagisa / rust_libloading

Bindings around the platform's dynamic library loading primitives with greatly improved memory safety.
https://docs.rs/libloading
ISC License
1.24k stars 102 forks source link

Add endpoint that allows compile time escaped strings #116

Closed HookedBehemoth closed 1 year ago

HookedBehemoth commented 1 year ago

Currently libloading only has one path for loading symbols which assumes strings can be improperly escaped. Many crates use libloading with autogenerated code which could easily ensure strings are formed right at compiled time.

Also aren't the results from dlerror static? Is there any reason why they are copied into a CString again?

nagisa commented 1 year ago

Currently libloading only has one path for loading symbols which assumes strings can be improperly escaped. Many crates use libloading with autogenerated code which could easily ensure strings are formed right at compiled time.

I’m not entirely sure what you mean, can you clarify? Are you referring to this? https://github.com/nagisa/rust_libloading/blob/6e284984aee68cc2d1b7e7d5e7b5a2a2279cf8e3/src/util.rs#L7-L25

In that case my hands are somewhat tied as the complaint is more about how CStr works, rather than anything else. Once CStr no longer requires no interior null bytes, libloading will be able to drop this requirement as well (in practice we could do it already, but I don't really want to diverge from the rest of the ecosystem's conventions, and those are set by libstd here.)

Also aren't the results from dlerror static? Is there any reason why they are copied into a CString again?

They aren’t guaranteed by the standard, no. Calling dlerror a second time may release the error message returned by the previous call to dlerror, hence the copy.