Skip to content
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

Add Ptr::to_option method #6604

Closed
wants to merge 2 commits into from

Conversation

brendanzab
Copy link
Member

No description provided.

#[inline(always)]
fn to_option(&const self) -> Option<T> {
if self.is_null() { None } else {
Some(unsafe { **self })
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm concerned about this line. Will this be problematic?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, to_option isn't a safe function. Raw pointers can point to invalid locations so the unsafe block is incorrectly assuming the operation is safe.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dang, yeah that makes sense. I dunno if this is a lost cause then. :(

@brson
Copy link
Contributor

brson commented May 19, 2013

Converting unsafe pointers to Option-something seems useful but this implementation has a couple things that concern me.

It looks like it is returning a copy of T and doing so without a Copy bound. It's possibly unsafely copying, so adding a test for ~int may be revealing. Making a copy by default seems surprising. Would something returning Option<&T> (or Option<&mut T> for *mut T) be useful?

It should be unsafe because it dereferences an arbitrary pointer.

@brendanzab
Copy link
Member Author

@brson Fixed to use an Option<&T>

bors added a commit that referenced this pull request May 21, 2013
@bors bors closed this May 21, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Mar 25, 2021
`match_wildcard` improvements

fixes: rust-lang#6604
fixes: rust-lang#5733
fixes: rust-lang#6862

rust-lang#5733 is only fixed in the normal case, if different paths are used for the variants then the same problem will occur. It's cause by `def_path_str` returning an utterly useless result. I haven't dug into why yet.

For rust-lang#6604 there should be some discussion before accepting this. It's easy enough to change the message rather than disable the lint for `Option` and `Result`.

changelog: Attempt to find a common path prefix for `match_wildcard_for_single_variants` and `wildcard_enum_match_arm`
changelog: Don't lint op `Option` and `Result` for `match_wildcard_for_single_variants` and `wildcard_enum_match_arm`
changelog: Consider `or` patterns and `Self` prefix for `match_wildcard_for_single_variants` and `wildcard_enum_match_arm`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants