Safe APIs should be safe, unsafe APIs should be marked unsafe

[langston-barrett]

Describe the bug

I can write a program without using unsafe that segfaults.

To Reproduce

$ cat > libafl/examples/unsafe.rs <<EOF
use libafl::prelude::{tuple_list, ListObserver, MatchName, TimeObserver};

fn main() {
    let ot = tuple_list!(TimeObserver::new("name"));
    let lo = ot.match_name::<ListObserver<()>>("name").unwrap();
    println!("{}", lo.list().len());
}
EOF

$ cargo run --quiet --example unsafe

zsh: segmentation fault (core dumped)  cargo run --example unsafe

$ git rev-parse HEAD

64a57ad3e3802cfff711c4b6dd8f42b8c19bfd01

Expected behavior

The Rust convertion is that any program that doesn't use unsafe should not be subject to memory corruption. In cases where the library can't guarantee this, the API in question should be marked unsafe.

Additional context

I've phrased this issue pretty generally, though I've reported a very specific instance. The reason is: I think there's a lot of unsafe code in LibAFL, and I wonder if there are other places where this expectation is violated.

The relevant code for the specific problem noted above is here:

https://github.com/AFLplusplus/LibAFL/blob/53dba5f49d035006b435d7ef652cf3c7a9b0ecde/libafl/src/bolts/tuples.rs#L35-L41

[domenukk]

I think in this specific case (and probably most cases) it's better to try and build a safe wrapper. But in general you are right of course!

[addisoncrump]

Can we replace this with type_id?

[andreafioraldi]

Can we replace this with type_id?

No because it enforces 'static. This is unsafe only in stable, while safe with nightly rust. It is more of a WIP API, ofc we can mark it unsafe but will be safe in the future

[domenukk]

This specific example is fixed by removing the unsafety (mostly) Other examples still persist across the codebase, I add some needed unsafe specifiers in #1398

[domenukk]

Closing this for now, I think we are at a better state now