os/unix/lib.rs implementation passes non-zero-terminated strings to dlopen/dlsym

[rzheka]

E.g.:

let path_to_lib_str =
            path_to_lib
                .as_ref()
                .to_string_lossy();
        let path_to_lib_c_str = path_to_lib_str.as_ptr() as *const c_char;

here path_to_lib_c_str is not really a c_str, but a pointer to a regular Rust utf8 string slice. The issue can be reproduced with something like this:

let name = "mylib.so123";
LibUnsafe::new(&name[0..8]).unwrap();

where mylib.so is a valid shared lib that can be located by dlopen.

[Maximiato]

Have a patch for dlopen if people are interested. If I apply the same to dlsym, cargo test fails because it seems like an optional \0 termination in the argument passed to find_func is used as a feature. See examples in lib_impl/lib.rs.

[tyleo]

I am interested!

[Maximiato]

Ah, I understand now, the strings that are passed to dlsym go through util::null_terminate before they get there. Looks like this isn't a problem on the windows side either, so I think we should be good with just the fix for dlopen.