Add endpoint that allows compile time escaped strings

[HookedBehemoth]

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?

[Simonas Kazlauskas]

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?

rust_libloading/src/util.rs

Lines 7 to 25 in 6e28498

 /// Checks for the last byte and avoids allocating if it is zero. 
 /// 
 /// Non-last null bytes still result in an error. 
 pub(crate) fn cstr_cow_from_bytes(slice: &[u8]) -> Result<Cow<'_, CStr>, Error> { 
     static ZERO: raw::c_char = 0; 
     Ok(match slice.last() { 
         // Slice out of 0 elements 
         None => unsafe { Cow::Borrowed(CStr::from_ptr(&ZERO)) }, 
         // Slice with trailing 0 
         Some(&0) => Cow::Borrowed( 
             CStr::from_bytes_with_nul(slice) 
                 .map_err(|source| Error::CreateCStringWithTrailing { source })?, 
         ), 
         // Slice with no trailing 0 
         Some(_) => { 
             Cow::Owned(CString::new(slice).map_err(|source| Error::CreateCString { source })?) 
         } 
     }) 
 } 

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.