Skip to content

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

Closed
@nikomatsakis

Description

@nikomatsakis
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;
}

Activity

nikomatsakis

nikomatsakis commented on Sep 12, 2012

@nikomatsakis
ContributorAuthor

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

jruderman

jruderman commented on Sep 12, 2012

@jruderman
Contributor

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

In C++, POD structs can contain pointers.

jruderman

jruderman commented on Sep 12, 2012

@jruderman
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

nikomatsakis commented on Sep 12, 2012

@nikomatsakis
ContributorAuthor

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

nikomatsakis commented on Nov 5, 2012

@nikomatsakis
ContributorAuthor

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

nikomatsakis commented on Nov 5, 2012

@nikomatsakis
ContributorAuthor

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

Aatch

Aatch commented on May 10, 2013

@Aatch
Contributor

Closed by #6354

added a commit that references this issue on Apr 20, 2024

Auto merge of rust-lang#3471 - RalfJung:blocked, r=RalfJung

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @nikomatsakis@Aatch@jruderman

        Issue actions

          RFC: zero initializer / undefined intrinsics for POD types · Issue #3471 · rust-lang/rust