Skip to content

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

Closed
sp3d opened this issue Feb 24, 2014 · 3 comments
Closed

No safe way to get a raw ptr to an uninitialized variable #12528

sp3d opened this issue Feb 24, 2014 · 3 comments

Comments

@sp3d
Copy link
Contributor

sp3d commented Feb 24, 2014

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:

fn main(){
    let a: int;
    let b: *int = &a;
}

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.

@thestinger
Copy link
Contributor

I don't really think this is necessary. There's the uninit function for declaring an uninitialized variable. The ability to create raw pointers without unsafe is more of a novelty than something useful (real pointer arithmetic via offset is unsafe anyway).

@sp3d
Copy link
Contributor Author

sp3d commented Feb 25, 2014

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).

@thestinger
Copy link
Contributor

The &a operation here returns &int, not *int, which is then coerced to a raw pointer. It's not clear how this could actually be implemented. Regardless, it's a fundamental language change and would need to go through the RFC process. It's not a missing low-level capacity since mem::uninitialized provides the functionality.

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 25, 2022
fix: Check for the correct proc-macro settings in missing proc-macro diagnostics
flip1995 pushed a commit to flip1995/rust that referenced this issue Apr 4, 2024
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
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

No branches or pull requests

2 participants