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?
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.
This parting shot sounds pretty dire
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
unsoundthis is unsound, since it can be called from safe code introducing UB). Or am I wrong? Is the fundamental value proposition of rust moot?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.