-
Notifications
You must be signed in to change notification settings - Fork 48
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
Evaluate unsafe code in encoder #52
Comments
It looks like the compiler is smart enough to optimize code making a 16-bit value from two consecutive 8-bit values in an array using I'll see how it plays out in the actual code next. |
Right, 3b7208b removes most of the remaining unsafe in the encoder. The only two bits now are the unaligned reads, which have bounds checks right before them. I checked over the other unsafe uses and couldn't find any unsoundness. They were however not well isolated to avoid any code change that could affect the soundness. There was only a marginal performance improvement at best so I just removed it anyhow. We can look into minor safe performance tweaks later. |
Sounds like a great time for a point release! For the record, it should be possible to eliminate unaligned reads as well using the trick from #48, but that requires rustc 1.34. |
Debian Stable is now on 1.34, Ubuntu is on 1.35 and Fedora is on 1.36. How do you feel about making a point release immediately, so that people stuck on old compilers could get at least some of the safety improvements, then converting the remaining unaligned loads to safe code and issuing another point release with an MSRV version bump? |
Sounds good. I've published a new version. Will look at updating the rest later. |
Closing as there is no remaining unsafe code in the core crate. |
There are still a number of uses of unsafe in the encoder code, more specifically in the match finding code to avoid bounds checks inside tight loops. While we've looked over them before, it would be a good idea to check them again and try to get rid of as many as we can if they have no or negligible effect on performance. In many of the unsafe calls the compiler may already be able to optimize them away anyhow.
The only unsafe code in the decoder are simple bytes to integer conversions, which should be sound.
Once 1.34 is reliably available in distros, we can switch to using the built-in functions for converting from bytes to integers.
The text was updated successfully, but these errors were encountered: