Rust

5979 readers

112 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

EdTheLegendary@programming.dev

kahnclusions@programming.dev

torcherist@programming.dev

The rabbit hole of unsafe Rust bugs – notgull – The world's number one source of notgull (notgull.net)

submitted 11 months ago by snaggen@programming.dev to c/rust@programming.dev

6 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] KillTheMule@programming.dev 4 points 11 months ago* (last edited 11 months ago) (1 children)

This parting shot sounds pretty dire

a bug in safe code can easily cause unsound behavior in your unsafe code if you’re not careful.

That's definitely not how it should be. Fortunately, I think I disagree with that, since miri points to the "real" buggy code:

unsafe { inner.as_ref() }

As opposed to the article, I'd argue this code is not correct, since it did not account for alignment, which it must (I mean, by standard use of the word unsound this is unsound, since it can be called from safe code introducing UB). Or am I wrong? Is the fundamental value proposition of rust moot?

[–] KiranWells@pawb.social 5 points 11 months ago

I believe you are correct; if the unsafe code can cause undefined behavior if input data is not following a specific contract, then the entire function should be labeled unsafe so the caller knows that.

The other option is to check to make sure the contract is valid, and return an error or panic if it is not. That function would be sound, as no inputs cause undefined behavior.