These are not the same:
use libc::c_char;
use std::os::raw::c_char;
Looking at the definitions, std::os::raw::c_char is defined as a u8 while libc::c_char is defined as i8.
If I have FFI functions, which would I want to use? I'm thinking std::os::raw::c_char but I wanted clarity before I make changes....
Thnx
Matt
It depends on the platform whether C's char is signed or unsigned. You can see the giant #[cfg] on std's c_char here, whereas libc has the definitions spread throughout different modules -- but hopefully they do agree for any given platform!
That make sense.
What triggered my curiosity is Pycharm (using rust plugin) triggered an error on passing a c_char from one function to another in a separate module. In one module, the c_char was from libc and in the other module used std.
It seems like they should both be resolving to the same type. So, could this just be a pycharm + rust plugin problem?
Thnx
Matt
To the compiler, type aliases are considered identical to the assigned type. So as long as both c_char really are defined the same way, there shouldn't be any problem.
Maybe Pycharm doesn't realize this, or maybe it's conservatively supposing that they could be different in some configurations -- I'm not sure. Is the error coming from Pycharm itself, or are they just presenting an error that was captured from rustc?
Here's the error:
The consumer function got (as input defined as libc::c_char) config_str and passed it to deserialize_arguments which uses std::os::raw::c_char
Matt
That does look like a real rustc error -- what is the target platform?
MacOS. No specific targets are defined in the toml.
[lib]
name = "mylib"
path = "src/lib.rs"
crate-type = ["staticlib", "rlib", "cdylib"]
The code looks like this
in mod.rs
use libc::c_char;
#[no_mangle]
pub extern "C" fn address_handler(
config_str: *const c_char
) -> i32 {
deserialize_arguments(config_str)
}
in utils.rs
use std::os::raw::c_char;
pub fn deserialize_arguments(
json_config: *const c_char
)
Thnx
Matt
I'm not sure what's going on. AFAICT, they should both get type c_char = i8; on all apple targets.
Yeah, nah. 