Unexpected reporting of unsafe when using libc crate as dependency

[ginger51011]

I have a minimal example containing the following

fn main() {
    let m = std::mem::size_of::<i64>();
    let p: *const i64 = unsafe { libc::malloc(m) } as *const i64;
    let n = unsafe { *p };
    println!("Found {n} at allocated memory");
}

My issue is that I expect cargo-geiger to report that one unsafe function from libc is used (libc::malloc, see libc docs), however only the two unsafe expressions (pointer dereference and the function call itself) are reported.

Is this the desired behavior? It could also be that libc is special in some way, because it does not seem to report the amount of unsafe functions I would expect. I see that there are some closed issues on libc and its macro behaviour, but then the current reporting might be a bit misleading.

[pinkforest]

The usual problem aroung soudness are the safe wrappers that wrap around "unsafe API" and mark them as safe to use.

"unsafe API" itself that is used via libc library is another thing -

libc is a "glue" or FFI that is behind extern "C" that wraps the libc C API to Rust thus difficulty reporting FFI.

libc as a Rust crate library has marked the bits as unsafe that need unsafe code to invoke by the caller.

e.g. libc has effectively indicated that anyone using it will be responsible - by marking the accessor as unsafe - but libc itself doesn't make those guarantees on behalf of the caller where the caller now is responsible given all the guarantees have been dropped.

In this case auditor should start looking code here given libc doesn't make any claims around that it's supposedly guaranteed safe to use.

if libc would provide the safe wrappers then yes desired behaviour would be to implicate "hey check libc as it's claiming guarantees that some unsafe is safe behind its safe"

As to reporting the C API is also the case with -sys crates that brings other FFI bindings.

Another thing we need to be looking at is macro expand as macros are difficult to get right.