-
-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Safe APIs should be safe, unsafe APIs should be marked unsafe #1095
Comments
I think in this specific case (and probably most cases) it's better to try and build a safe wrapper. |
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 |
This specific example is fixed by removing the unsafety (mostly) |
Closing this for now, I think we are at a better state now |
Describe the bug
I can write a program without using
unsafe
that segfaults.To Reproduce
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 markedunsafe
.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:
LibAFL/libafl/src/bolts/tuples.rs
Lines 35 to 41 in 53dba5f
The text was updated successfully, but these errors were encountered: