Change Handle representation to be non-nullable so that Option<Handle> is FFI-safe #309
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While I rewrote the OUT pointers in UEFI methods to use
MaybeUninit
(which actually looks very clean and logical) to avoid ever having null handles, the reason for the repr change is so that whenever an UEFI method accepts a handle - by the docs it can be optional or not, and this can be expressed by just having eitherHandle
orOption<Handle>
in the fn-pointer args, which is very clean and removes the need for null handles (Handle::unitialized()
) to ever exist on Rust side.I spent a night debugging my impls of (dis)connect_controller (that I will make a PR for too at some point) only to realize that I automatically assumed that whatever I did in the PR was already there ¯_(ツ)_/¯