-
Notifications
You must be signed in to change notification settings - Fork 31
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
Consider replacing safe-encode
feature by unsafe
APIs
#31
Comments
Sorry for the late reply. I agree that two different API has some advantages for soundness and documentation. |
I think I will go forward with this by inverting the feature flags. e.g. Additionally there will be That means |
With version
I didn't invert the other feature flags as I want to minimize the API breakage. |
This is an old issue but if I may add a few thoughts. Currently, if a crate transitively enables the safe compressor/decompressor then all lz4 usages in the build will also use that. And of course the reverse could apply, if someone wanted safe code they could get unsafe. -- I've been bit by this one. |
Used with
lz4_flex = { version = "0.9.0", default-features = false }
, we currently violate Rust's premise that code withoutunsafe
must not result in UB/unsound code.Specifically, it is surprising that I lose soundness guarantees by changing from
to
since it is quite difficult to detect that such a change has soundness implications.
One mechanism to avoid this issue is to offer two APIs: an
unsafe
that does not perform checks, and a safe one, that performs the checks (instead of a feature-based safety checking).The text was updated successfully, but these errors were encountered: