Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust: Box Is a Unique Type

blog.nilstrieb.dev

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Rust: Box Is a Unique Type

#41

Post by vishalontheline »

andy_xor_andrew wrote: post #14

One of the biggest struggles I have (and others have, judging from Stack Overflow) is how to generically handle accepting types of Box , Rc , T, Pin , &T, &mut T, etc etc. Of course you can write a function that is generic on > or something, but the moment you introduce function-coloring stuff like async, object safety, etc, things explode.

Is there an ELI5 video / tutorial for all things box-variables that you can recommend?

I understand pointers, I understand references, I understand ownership and mutability. I feel lost with Box things. The official documentation came across as cryptic to me and I had a hard time getting over the syntax. Like, what is "T" and why does it get passed into Box ... etc.

Re: Rust: Box Is a Unique Type

#42

Post by mmastrac »

LegionMammal978 wrote: post #38
mmastrac wrote: post #19

Earlier quoted context omitted.

I'm not aware of any UB that can 1) be caused by unique pointer violations from Box and 2) are undetectable by Miri (assuming good code coverage), but I might be wrong about this.

If you have an object that's !Unpin, then Miri will not apply uniqueness rules to anything containing it [0], including boxes and &mut references. (In the example code, replacing the PhantomPinned with a () will make Miri complain again.) This is considered a temporary (if long-lived) measure to allow async executors to manipulate pinned futures without invalidating all their internal borrows. Thus, it might be seen…

I forgot about this. I actually had to ignore a test in Miri because of this exact issue.

https://github.com/denoland/deno_core/blob/98b09fa4f77db1131...

Anxiously waiting on https://github.com/rust-lang/rfcs/pull/3467

Re: Rust: Box Is a Unique Type

#43

Post by mmastrac »

IshKebab wrote: post #32
mmastrac wrote: post #27

Earlier quoted context omitted.

This is trivially solved by putting code coverage and Miri into the same project, however.

It's trivial to measure code coverage. It's definitely not trivial to achieve 100% code coverage. This is the sort of "just do things perfectly" nonsense we get from C programmers. I'm surprised to see it from Rust devs, given the whole ethos of Rust is that it acknowledges that programmers are not perfect and helping them avoid bugs as much as possible is a good thing.

It's not nonsense. It's really not difficult to structure code for 100% coverage of unsafe code if you're thinking about it from the start.

You're also perfectly fine to write code that is free of `unsafe`, freeing you from this onerous task. We're pulling out Miri _because_ we're going outside the normal guardrails.

You also don't _need_ to get 100% coverage of all your unsafe code if you can be confident of the usage of unsafe. The most complex unsafe code should almost certainly be covered, but there are a lot of trivial uses of unsafe that can be shown to be correct through reasoning.

Where possible I prefer to split code into safe and unsafe portions, and test the unsafe portions under Miri with as much coverage as gives me confidence in the code.

I've made UB mistakes before with unsafe, but since adding Miri and code coverage, the numbers of mistakes I've made has dropped dramatically. No programmer is perfect, but one would be pretty foolish to ignore the tools at one's disposal.

Re: Rust: Box Is a Unique Type

#44

Post by mmastrac »

andy_xor_andrew wrote: post #14

One of the biggest struggles I have (and others have, judging from Stack Overflow) is how to generically handle accepting types of Box , Rc , T, Pin , &T, &mut T, etc etc. Of course you can write a function that is generic on > or something, but the moment you introduce function-coloring stuff like async, object safety, etc, things explode.

I wrote https://github.com/mmastrac/keepcalm as a way to help with this, especially for writing webserver-like code. For most cases this type of code can take a small perf hit in exchange for drastically simplifying the sharing of data in the system.

Re: Rust: Box Is a Unique Type

#45

Post by vlovich123 »

Rusky wrote: post #28
ComputerGuru wrote: post #5

I have to disagree with the entire premise of the article. It's the fact that Box isn't unique that gives it this behavior. The author even says as much, but dismisses it because it gets in the way of their point: > While it can be argued that box is like a T, but on the heap, and therefore moving it should invalidate pointers, since moving T definitely has to invalidate pointers to it, this comparison doesn’t make s…

The problem with this, as the article argues in detail, is that it leaves a hole in functionality that people need but offers no clear benefit in return. A movable owning pointer that exposes its pointer-ness in its semantics is a useful tool when you're doing lower-level, sometimes-unsafe stuff with memory layout. The author points out that, because Box does not currently provide this functionality, there are crates…

I think the better approach would be to standardize some kind of feature that lets you annotate variables as "not noalias" so that Rust knows to elide the noalias for those values. That's a much more generic way to solve the ecosystem problem without changing Box semantics or introducing one off types. That being said, there's already a solution in the ecosystem which is to not use aliased pointers after giving the pointer to Box & moving it.

Re: Rust: Box Is a Unique Type

#46

Post by [deleted] »

3836293648 wrote: post #24
andy_xor_andrew wrote: post #14

One of the biggest struggles I have (and others have, judging from Stack Overflow) is how to generically handle accepting types of Box , Rc , T, Pin , &T, &mut T, etc etc. Of course you can write a function that is generic on > or something, but the moment you introduce function-coloring stuff like async, object safety, etc, things explode.

You just write an &T version and let everyone coerce their smart pointer into a reference on call? Worst case you write your generic asref function and then immediately delegate to the &T version

[deleted]

Re: Rust: Box Is a Unique Type

#47

Post by remram »

orf wrote: post #39
remram wrote: post #33

Earlier quoted context omitted.

> A box is a pointer AND the storage at the same time. That's just the way you decide to see it. Most people don't, in fact the actual documentation is quite different: >> A pointer type that uniquely owns a heap allocation of type T. This explicitly describes it as a pointer, pointing to a single allocation. https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html

“A pointer type that owns a heap allocation” is a more broad definition to me than specifically “a pointer pointing to a single allocation”

You don't think "own" is more specific than "point"? How could it own it without pointing to it?

Re: Rust: Box Is a Unique Type

#48

Post by vlovich123 »

mmastrac wrote: post #9

I strongly disagree with this article. Perhaps in the days before Miri it might have made sense, but it's pretty trivial right now to discover UB in unsafe code with a simple `cargo +nightly miri test` run. It feels like the Rust team is a bit wary of introducing other optimizations for fear of breaking unsafe code that has lurking UB, but it's better to start working on fixing these problems _now_ rather than get st…

I'm using the glommio runtime & miri takes forever to just start the executor & then throws up with "can't call foreign function `sched_setaffinity` on OS `linux`".

Aside from clearly a very long tail of blockers from running it on non-trivial program on tier 1, the slowness is a real usability problem. It's slower than valgrind afaict.

I think dismissing issues as "but we have miri" is very short sighted and it's not clear to me that Miri will ever reach the point of catching issues in substantial codebases (the standard library is substantial in number of lines, but not substantial in terms of exercising all the OS features).

Re: Rust: Box Is a Unique Type

#49

Post by wtetzner »

andy_xor_andrew wrote: post #14

One of the biggest struggles I have (and others have, judging from Stack Overflow) is how to generically handle accepting types of Box , Rc , T, Pin , &T, &mut T, etc etc. Of course you can write a function that is generic on > or something, but the moment you introduce function-coloring stuff like async, object safety, etc, things explode.

Yeah, I typically use `impl AsRef`. It would be really nice to be able to say roughly the same thing, but have the `.as_ref()` call happen at the call site instead of within the function.

Re: Rust: Box Is a Unique Type

#50

Post by [deleted] »

remram wrote: post #47
orf wrote: post #39

Earlier quoted context omitted.

“A pointer type that owns a heap allocation” is a more broad definition to me than specifically “a pointer pointing to a single allocation”

You don't think "own" is more specific than "point"? How could it own it without pointing to it?

[deleted]
Post reply on HN