-
Notifications
You must be signed in to change notification settings - Fork 13.3k
No safe way to get a raw ptr to an uninitialized variable #12528
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
I don't really think this is necessary. There's the |
It would still be nice to have this possible without an unsafe block, but it didn't come to mind that uninit() would work as a trapdoor here. Oversafety is less of a problem than inability to express immutable circular references. It would be nice if we explicitly stated in docs that the reason to use uninit is to convince the compiler that a variable has been initialized without actually doing the work to initialize it (which is, of course, unsafe in general, unlike the suggested feature). |
The |
fix: Check for the correct proc-macro settings in missing proc-macro diagnostics
Do not warn on .map(_::clone) for Arc, Rc, and their weak variants Those constructions are idiomatic, and using `Arc::clone(x)` and `Rc::clone(x)` is often the recommended way of cloning a `Arc` or a `Rc`. Fix rust-lang#12528 changelog: [`map_clone`]: do not warn on `.map(_::clone)` for `Arc`, `Rc`, and their `Weak` variants
I would argue that the following code is safe (rustc presently disagrees: "error: use of possibly uninitialized variable:
a
") and there should be a way to write it:The analysis is correct in that obtaining an &-ptr to an uninitialized variable allows for unsafety, but there should be a way to get the address of a variable as a raw-ptr without needing a guarantee that a valid value lives at that address.
The text was updated successfully, but these errors were encountered: