Uninitialized memory: Unsafe Rust is too hard • Hacker News Board

Re: Uninitialized memory: Unsafe Rust is too hard

#121

Post by gulbanana » Tue, Feb 01, 2022, 5:14 AM UTC

remram wrote: post #104

nickitolas wrote: post #100

Earlier quoted context omitted.

No, this is specifically not creating a mutable reference. So it's fine except for the fact that writing via assignment like this calls the destructor/drop for the old value, if the type has a Drop implementation. That's why &str is fine but String is not, since it will call Drop on a zeroed String (Which is not guaranteed to work) or on an uninitialized String. Using ptr::write instead explicitly does not Drop the o…

Do you have a source/explanation for *role not being a mutable reference? What is this expression's type then? You mention ptr::write() but it is not used here, and I don't see how you could use it to write to a field?

(*role) is not a reference at all, it is a value. its type is Role.

Re: Uninitialized memory: Unsafe Rust is too hard

#122

Post by xorvoid » Tue, Feb 01, 2022, 2:15 PM UTC

comex wrote: post #34

xorvoid wrote: post #29

Earlier quoted context omitted.

I’ve never understood why they don’t just support partially initialized structs. They’re already doing control flow analysis for initializing variables. It seems like a natural extension to do this for aggregate types (product and sum). From a type theory perspective, a struct T is not a T in unitialized state, it’s. “partial T” that at some point gets transformed into a T. So, you’d not be able to use the T in the n…

Rust already supports partially de initialized structs - that is, moving out of a struct field by field - and there’s no fundamental reason it can’t support partial initialization too. Indeed, there’s an open issue for it: https://github.com/rust-lang/rust/issues/54987 But there are a lot of desired features with open issues, so don’t expect this to be implemented anytime soon unless someone takes an interest in it.

Ah okay this makes sense. I wish I personally had the spare time to contribute this.

Re: Uninitialized memory: Unsafe Rust is too hard

#123

Post by Ericson2314 » Tue, Feb 01, 2022, 5:58 PM UTC

CheezeIt wrote: post #105

Ericson2314 wrote: post #90

Earlier quoted context omitted.

> In the spirit of being charitable You are being nice, but even if there is a documentation error, we can prove that if safe rust isn't completely broken, and `& x.field` is allowed in safe Rust, then fields must be aligned. It is just preposterous Rust would be more broken than C in this regard. > but the syntax is clunkier, you have to use function calls instead of concise operators like * and ->. Yes I agree, the…

There could be some loophole. If the program globally never makes a reference to a field, must it be aligned? If the field is referenced, could it be that when making a reference, the field gets copied or moved out and a reference is implemented as a pointer to that copy?

> If the program globally never makes a reference to a field, must it be aligned?

That would be whole-progam analysis which isn't done.

> If the field is referenced, could it be that when making a reference, the field gets copied or moved out and a reference is implemented as a pointer to that copy?

This breaks down with mutation, especially atomics, which are allowed as struct fields.

Re: Uninitialized memory: Unsafe Rust is too hard

#124

Post by remram » Tue, Feb 01, 2022, 8:57 PM UTC

gulbanana wrote: post #121

remram wrote: post #104

Earlier quoted context omitted.

Do you have a source/explanation for *role not being a mutable reference? What is this expression's type then? You mention ptr::write() but it is not used here, and I don't see how you could use it to write to a field?

(*role) is not a reference at all, it is a value. its type is Role.

lvalue not mutable reference, got it. I'm surprised there are contexts where one is fine but the other is UB, but I understand the rule.

Re: Uninitialized memory: Unsafe Rust is too hard

#125

Post by CheezeIt » Wed, Feb 02, 2022, 3:23 PM UTC

Ericson2314 wrote: post #123

CheezeIt wrote: post #105

Earlier quoted context omitted.

There could be some loophole. If the program globally never makes a reference to a field, must it be aligned? If the field is referenced, could it be that when making a reference, the field gets copied or moved out and a reference is implemented as a pointer to that copy?

> If the program globally never makes a reference to a field, must it be aligned? That would be whole-progam analysis which isn't done. > If the field is referenced, could it be that when making a reference, the field gets copied or moved out and a reference is implemented as a pointer to that copy? This breaks down with mutation, especially atomics, which are allowed as struct fields.

> That would be whole-progam analysis which isn't done.

That doesn’t matter.

> This breaks down with mutation, especially atomics, which are allowed as struct fields.

Not true at all. First, the compiler could refrain from doing this sort of code generation on fields with atomics (or any kind of mutable cell). Second, the object could be misaligned in some local contexts sometimes but references passed to functions could be always properly aligned. So a RefCell or atomic could still be copied or moved out and mutated, then moved back in, when the object is known not to have any references.

In general, this is close to reasonable code generation — a local struct could have some of its parts in registers. Its parts might be in noncontiguous stack locations. A language spec needs to specify that a field can be referenced or accessed via its pointer. It might also distinguish this from an alignment guarantee.

Re: Uninitialized memory: Unsafe Rust is too hard

#126

Post by Ericson2314 » Wed, Feb 02, 2022, 9:50 PM UTC

CheezeIt wrote: post #125

Ericson2314 wrote: post #123

Earlier quoted context omitted.

> If the program globally never makes a reference to a field, must it be aligned? That would be whole-progam analysis which isn't done. > If the field is referenced, could it be that when making a reference, the field gets copied or moved out and a reference is implemented as a pointer to that copy? This breaks down with mutation, especially atomics, which are allowed as struct fields.

> That would be whole-progam analysis which isn't done. That doesn’t matter. > This breaks down with mutation, especially atomics, which are allowed as struct fields. Not true at all. First, the compiler could refrain from doing this sort of code generation on fields with atomics (or any kind of mutable cell). Second, the object could be misaligned in some local contexts sometimes but references passed to functions c…

If the compiler is so omnicient, then you should just be able to take the pointer to the field in the unsafe struct too!

Surely such a genius compiler can see "oh, they took a field reference, better make sure that field is aligned" whether the reference is a safe one or not!

Re: Uninitialized memory: Unsafe Rust is too hard

#127

Post by DSMan195276 » Thu, Feb 03, 2022, 5:40 AM UTC

Ericson2314 wrote: post #123

CheezeIt wrote: post #105

Earlier quoted context omitted.

There could be some loophole. If the program globally never makes a reference to a field, must it be aligned? If the field is referenced, could it be that when making a reference, the field gets copied or moved out and a reference is implemented as a pointer to that copy?

> If the program globally never makes a reference to a field, must it be aligned? That would be whole-progam analysis which isn't done. > If the field is referenced, could it be that when making a reference, the field gets copied or moved out and a reference is implemented as a pointer to that copy? This breaks down with mutation, especially atomics, which are allowed as struct fields.

> That would be whole-progam analysis which isn't done.

Yet.