-
Notifications
You must be signed in to change notification settings - Fork 285
Should we use MaybeUnint
?
#469
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
Comments
Concept ACK -- though I'd like to see how invasive it is. I guess we currently use 0-initialization everywhere that we'd "naturally" use uninitialized bytes? IIRC a long time ago we did use |
Man, things like this make me really wish x-lang-LTO were more broadly deployed. It would avoid us having to think too much about this - LLVM would mostly be able to remove the 0-init, at least in theory... |
I have a feeling this will not affect performance in any way. Also, MaybeUninit doesn't always optimize well: e.g. rust-lang/rust#74267 And this will elevate logic bugs into memory bugs, so I'm not sure I'm in favor for this unless anyone can prove performance benefits |
Yes.
Sounds like a strong argument to me.
Yep, in theory. IDK how exactly the algos work on the C side, but it's possible LLVM can't see the bytes are initialized.
I guess some of the operations are not that expensive? Perhaps it could make sense to use
That issue is actually resolved, it was reopened only for adding tests. I think fixing obvious opt bugs is a better approach than leaving questionable code around. |
Without x-language-LTO it cannot, and that is generally not ever enabled because cc-rs is a bit overly conservative. |
I mean, I was questioning whether it can even with x-lang-LTO. :)
Didn't know, would be nice to improve one day. |
At first I thought
MaybeUninit
isn't used out of paranoia but now I realized it was because of MSRV. We can use it now. There's a bunch of places where it should be usable - mainly out parameters in C functions.Pros/cons/thoughts:
assume_init
only on successI personally prefer to do it if upstream can guarantee at least that if a call succeeds the memory is fully overwritten.
The text was updated successfully, but these errors were encountered: