Skip to content
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

Refactor for Increased Safety without Performance Impacts #135

Merged
merged 14 commits into from
Sep 14, 2024
Merged

Conversation

Alexhuszagh
Copy link
Owner

This introduces numerous different layers of security enhancements:

  1. Removal of most unsafe code (according to count-unsafe, the code went from 160 unsafe functions and 3088 unsafe exprs to 8 unsafe functions and 1248 unsafe exprs, However, all the remaining unsafe code has much clearly documented safety guarantees and is isolated into safe abstractions.
  2. Clear documentation of the locations where unsafe code is used and at the crate-level documentation so it's clearly visible.

Closes #100.

This converts the core dragonbox algorithm for the float decimal writers
to be completely safe. This ensures effectively all non-trivial uses of
unsafe that could cause unsoundness are removed for 99% of users.
This causes ~0.5-1% regression in performance but this is well within an
acceptable range for better safety guarantees. Most of the bounds
checking is ellided by the compiler.
This in general for simple cases due to slight refactoring improves performance, however, it does have a noticeable (+2-7%) penalty in some corner cases which invoke the close-to-halfway rounding cases. That said, performance of this implementation of the Dragonbox algorithm without any unsafety always outperforms Ryu, which means it's still the fastest implementation out there even with slight regressions in corner cases.
This is a relatively trivial change and causes a small performance hit, but that change should be able to be mitigated with some minor refactoring.
One specific benchmark however has significant regressions, the
random:big_ints/write_f32_lexical benchmark, while the f64 version does
not. The benchmark is still considerably faster than ryu or fmt,
however.
This does have some performance penalties but performance is still
excellent, and so a few patches will need to be made so our compiler can
elide more checks.
Performance enhancements will soon follow to restore any lost
performance in some cases which impacted it up to 3%.
@Alexhuszagh Alexhuszagh added the A-sec Issues with potential security implications. label Sep 14, 2024
@Alexhuszagh Alexhuszagh added this to the 1.0 milestone Sep 14, 2024
@Alexhuszagh Alexhuszagh merged commit 7c0100d into main Sep 14, 2024
39 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-sec Issues with potential security implications.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[OTHER] Improve internal safety comments and architecture
1 participant