You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Violating either is currently considered UB, while safety invariants can be temporarily violated provided that you don't pass it to any function expecting the safety invariants to hold, while violating the validity invariants is unconditionally UB1. As an example for bool the value being 0 or 1 is a validity invariant, while for str the value being valid UTF-8 is a safety invariant2.
257: Define undefined behavior for valid type values in terms of invariants r=kirtchev-adacore a=Veykril
We currently specify non-utf8 str values as UB which is not quite the case,
this PR changes how we describe undefined behavior for valid values of a type
by specifying either a validity invariant or a safety invariant for them.
Closes#150
Co-authored-by: Lukas Wirth <[email protected]>
Violating either is currently considered UB, while safety invariants can be temporarily violated provided that you don't pass it to any function expecting the safety invariants to hold, while violating the validity invariants is unconditionally UB1. As an example for bool the value being 0 or 1 is a validity invariant, while for str the value being valid UTF-8 is a safety invariant2.
Footnotes
https://www.ralfj.de/blog/2018/08/22/two-kinds-of-invariants.html ↩
https://github.com/rust-lang/reference/pull/792 ↩
The text was updated successfully, but these errors were encountered: