I do wonder... What is the most used package that includes an unsafe block? I mean, including transient uses. If one knows what that is, and re-implement the unsafe blocks in a safe way (or provide extra features in core to do it), the number of projects with unsafe would go way down.
@tylerfusco7495 I don't think uses of std "count" in this stat... Certainly not in the analysis the presentation is about. We're talking about userland rust code that has an "unsafe" block anywhere in it, not the compiler itself. If something is in std, any memory safety issues are a responsibility of the rust team, not a package maintainer who may or may not be willing to deal with further updating their package if a soundness issue is discovered.
@@boenrobot okay, but I'm looking at all of the most used rust crates, and serde, serde-json, syn, clap, rand, tokyo, etc etc. literally all use `unsafe` (to varying extents)
@tylerfusco7495 Yeah, all of those definitely do count... So the next question is if there is any feature rust could provide to allow the unsafe blocks to be turned into a safe ones... Even if actually implementing that feature would break BC. At the pace in which Rust operates, I wouldn't be surprised if, for many of those popular crates, there's already a combination of unstable nighly features to address the unsafe blocks... But because it is nightly only, and you never know how those features would change... it is not implemented by the crates yet.
@@boenrobot well from what i saw, no - usually unsafe blocks arent addressing a problem that safe rust can fix. it's stuff like avoiding utf8 validation checking, `unsafe impl Send/Sync`, or FFI calls.
Why doesn't he use the add method on the pointer, which will add the size of the type to the address for him?
Better if logos are all on the right for a bigger slide window.
22:55 unsafe blocks georg
I do wonder... What is the most used package that includes an unsafe block? I mean, including transient uses.
If one knows what that is, and re-implement the unsafe blocks in a safe way (or provide extra features in core to do it), the number of projects with unsafe would go way down.
including transient uses? std. even Vec just uses pointers (which are unsafe) to get the max performance
@tylerfusco7495 I don't think uses of std "count" in this stat... Certainly not in the analysis the presentation is about. We're talking about userland rust code that has an "unsafe" block anywhere in it, not the compiler itself.
If something is in std, any memory safety issues are a responsibility of the rust team, not a package maintainer who may or may not be willing to deal with further updating their package if a soundness issue is discovered.
@@boenrobot okay, but I'm looking at all of the most used rust crates, and serde, serde-json, syn, clap, rand, tokyo, etc etc. literally all use `unsafe` (to varying extents)
@tylerfusco7495 Yeah, all of those definitely do count... So the next question is if there is any feature rust could provide to allow the unsafe blocks to be turned into a safe ones... Even if actually implementing that feature would break BC.
At the pace in which Rust operates, I wouldn't be surprised if, for many of those popular crates, there's already a combination of unstable nighly features to address the unsafe blocks... But because it is nightly only, and you never know how those features would change... it is not implemented by the crates yet.
@@boenrobot well from what i saw, no - usually unsafe blocks arent addressing a problem that safe rust can fix. it's stuff like avoiding utf8 validation checking, `unsafe impl Send/Sync`, or FFI calls.