-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Replace unsafe security_attributes
function with safe inherit_handle
alternative
#145150
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
The `security_attributes` function is marked as safe despite taking a raw pointer which will later be used. Fortunately this function is only used internally and only in one place that has been basically the same for a decade now. However, we only ever set one bool so it's easy enough to replace with something that's actually safe.
rustbot has assigned @Mark-Simulacrum. Use |
@@ -80,7 +80,7 @@ pub struct OpenOptions { | |||
attributes: u32, | |||
share_mode: u32, | |||
security_qos_flags: u32, | |||
security_attributes: *mut c::SECURITY_ATTRIBUTES, | |||
inherit_handle: bool, |
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.
I spent some time wandering through other reviews and... interesting observation: people really don't like bool flags around here - readability issues, they say, I've been switching to enums myself, even for simple true/false cases
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.
I think this is much more relevant for function parameters, but this is mostly a struct field and so it's less relevant (I'd even argue marginally harmful).
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.
I'd just note that OpenOptions
uses bool
for most parameters. If this were a public API then we'd likely want to be consistent with those existing methods anyway.
@bors r+ rollup |
Rollup of 7 pull requests Successful merges: - #144553 (Rehome 32 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`) - #145064 (Add regression test for `saturating_sub` bounds check issue) - #145121 (bootstrap: `x.py dist rustc-src` should keep LLVM's siphash) - #145150 (Replace unsafe `security_attributes` function with safe `inherit_handle` alternative) - #145152 (Use `eq_ignore_ascii_case` to avoid heap alloc in `detect_confuse_type`) - #145200 (mbe: Fix typo in attribute tracing) - #145222 (Fix typo with paren rustc_llvm/build.rs) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #145150 - ChrisDenton:inherit, r=Mark-Simulacrum Replace unsafe `security_attributes` function with safe `inherit_handle` alternative The `security_attributes` function is marked as safe despite taking a raw pointer which will later be used. Fortunately this function is only used internally and only in one place that has been basically the same for a decade now. However, we only ever set one bool so it's easy enough to replace with something that's actually safe. In the future we might want to expose the ability for users to set security attributes. But that should be properly designed (and safe!).
…crum Replace unsafe `security_attributes` function with safe `inherit_handle` alternative The `security_attributes` function is marked as safe despite taking a raw pointer which will later be used. Fortunately this function is only used internally and only in one place that has been basically the same for a decade now. However, we only ever set one bool so it's easy enough to replace with something that's actually safe. In the future we might want to expose the ability for users to set security attributes. But that should be properly designed (and safe!).
The
security_attributes
function is marked as safe despite taking a raw pointer which will later be used. Fortunately this function is only used internally and only in one place that has been basically the same for a decade now. However, we only ever set one bool so it's easy enough to replace with something that's actually safe.In the future we might want to expose the ability for users to set security attributes. But that should be properly designed (and safe!).