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

RFC: zero initializer / undefined intrinsics for POD types #3471

Closed
nikomatsakis opened this issue Sep 12, 2012 · 8 comments
Closed

RFC: zero initializer / undefined intrinsics for POD types #3471

nikomatsakis opened this issue Sep 12, 2012 · 8 comments

Comments

@nikomatsakis
Copy link
Contributor

Perhaps we should add an intrinsic like:

fn zero<T: POD>() -> T

that basically fills T with zeros. This is perfectly safe for POD types. Of course, we don't have a POD kind yet, but that's a separate issue I guess. This is particularly useful in C interop, where you often have functions with out-params that otherwise need to be initialized by hand.

We could also add an intrinsic like

fn undefined<T: POD>() -> T

which would just leave the data uninitialized. This would be more efficient but less safe in some sense. Though restricting it to POD at least preserves memory safety, more-or-less.

The idea is you'd write something like:

struct FooResult { /*something POD*/ }

extern mod c_library { fn foo(p: &mut FooResult) -> bool; }

fn foo() -> FooResult {
    let result = defined();
    if !c_library::foo(&mut result) { fail; }
    return result;
}
@nikomatsakis
Copy link
Contributor Author

Here is an example that came up on IRC, but it comes up regularly: http://pastebin.com/v534PrDW. Sscroll to the final function.

@jruderman
Copy link
Contributor

Though restricting undefined to POD at least preserves memory safety, more-or-less.

In C++, POD structs can contain pointers.

@jruderman
Copy link
Contributor

@jruderman
Copy link
Contributor

I'd prefer to declare the C function as taking a &write FooResult, so the type-checker knows it can be uninitialized before the call and will be initialized after the call.

@nikomatsakis
Copy link
Contributor Author

In C++, POD structs can contain pointers.

Yeah, I wrote "more-or-less" because I figured *T would be POD, but not @T or ~T, but of course we don't make any guarantees about unsafe ptrs.

@nikomatsakis
Copy link
Contributor Author

So, it turns out that this exists! (the intrinsic init()) However, it does not check for POD and nor is it considered unsafe. Bad. See https://github.com/mozilla/rust/blob/master/src/libcore/comm.rs#L297. I'm gonna repurpose this issue to address its shortcomings.

@nikomatsakis
Copy link
Contributor Author

Oh, never mind, init() seems to fill with zero. It should still be unsafe.

@Aatch
Copy link
Contributor

Aatch commented May 10, 2013

Closed by #6354

@Aatch Aatch closed this as completed May 10, 2013
RalfJung pushed a commit to RalfJung/rust that referenced this issue Apr 20, 2024
threads: keep track of why we are blocked, and sanity-check that when waking up

Also remove support for condvars blocked on rwlocks, as that was no longer used.
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

3 participants