-
Notifications
You must be signed in to change notification settings - Fork 6
Remove unsafe constructs #3
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
Conversation
It isn't obvious that creating a Vec<u8> with uninitialised content is safe: https://www.ralfj.de/blog/2019/07/14/uninit.html#what-can-you-do-with-uninitialized-memory
This achieves the same optimisation as prior to 06958a9, but without using `unsafe`. Moreover, this avoids nested zip()s and iter_mut(), so it might be faster.
|
@hucsmn This should now be mergeable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your commits! Uninitialized vector may lead to UB if elements were readed before initialization. This is a premature optimization indeed, I would like to add some benchmarks later. For now, safe code is better.
Following codes could be simplified:
This is more concise and faster.
Again, faster and more concise.
|
Done, thanks for the feedback <3 |
qbsdiffusesunsafecode in various places to build uninitialisedVec<u8>s with a given size.Unfortunately, this probably is undefined behaviour, so it should be removed.
bsdiffunsaferemoved;bspatch:Context::{buf,dlt}caches are now managed safely.unsafecode is now forbidden within the crate.