Canvas unsafe code in the wild

[nikomatsakis]

I think we should organize a kind of "canvas" to find examples of how unsafe code is used in the wild. To start, it'd be great to enumerate a list of interesting places to look.

Here is my start at a list. Further nominations welcome. I'll try to keep the list up to date. Moreover, if you feel you've examined the source, open any relate issues and we can check it off.

• Standard library:
  • btree, esp. the iterators
  • hashmap
  • ...?
• External libraries:
  • rayon
  • take_mut
  • abomonation
  • ndarray
  • intrusive_collections by @Amanieu, cited in One glossary should be enough #19
  • rental

Other thoughts for packages? Is this a fruitful thing to examine?

[strega-nil]

Well, I think pcb would be a nice place to start, it's very simple and has some unsafe code that would be seen as UB by the "correct lifetime" style. (example)

[nikomatsakis]

@ubsan do you think that the "interesting patterns" in pcb are thus summarized by #12? If not, maybe you can write-up an issue that covers them?

[strega-nil]

I think they're well enough summarized. (see here) referencing pcb

[eternaleye]

Another use of unsafe code, this one more type-focused than lifetime-focused: https://github.com/Diggsey/query_interface

[Ericson2314]

https://github.com/nathan7/libfringe is wildly unsafe.

[nikomatsakis]

This discussion of how coroutines and scoped threads interact seems relevant, probably more as a negative case (i.e., enumerate where the coroutine abstractions goes wrong):

https://www.reddit.com/r/rust/comments/508pkb/unleakable_crate_safetysanityrefocus/d72703d

[arielb1]

This discussion of how coroutines and scoped threads interact seems relevant, probably more as a negative case (i.e., enumerate where the coroutine abstractions goes wrong):

That is more of a soundness issue than a memory model issue. scoped assumes that stack frames never leak - that a lifetime parameter passed to a function must live until the function exits (through a return or resume), while coroutines flat out violates that assumption.

[RalfJung]

I don't entirely understand what is the criterion for listing pieces of the standard library. Certainly RefCell is a very interesting bit of unsafe code, showing how far interior mutability can go and playing games with lifetimes that I have not yet seen in any other piece of unsafe code.

[mystor]

The problem with RefCell is that we aren't sure that its implementation won't invoke Undefined Behavior in a future model for what defines undefined behavior in unsafe rust. The fact that it holds a &'a reference which isn't actually valid for all of &'a, but only for either the lifetime of the Ref or RefMut, or 'a, whichever is shorter. This could be considered UB under some models as the lifetimes are "incorrect".

We aren't suggesting removing RefCell, it's just a question of whether its current implementation should be UB.

[RalfJung]

What I am asking is why RefCell is not listed above as "how unsafe code is used in the wild".

[nikomatsakis]

@mystor @RalfJung I think the only reason I did not list RefCell is that we have #5 already. My goal with this issue is not for it to exist permanently, just to serve as a clearing house of work to be done in terms of researching and then opening issues.

[RalfJung]

I see, that makes sense.

Notice that the trouble I am having with RefCell in my semantic model is entirely unrelated to #5. However, I am not sure if the memory model would be affected by that...

[arielb1]

Notice that the trouble I am having with RefCell in my semantic model is entirely unrelated to #5.

What's the trouble again?

[nikomatsakis]

@RalfJung if you see some other aspect of ref-cell that's not documented, please do open another issue...