From bac54ceb67ec86cfffadc8caaf4ff3c99c4a854d Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Thu, 23 Aug 2018 12:32:00 +0200 Subject: [PATCH] clarify boundary --- ralf/_posts/2018-08-22-two-kinds-of-invariants.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ralf/_posts/2018-08-22-two-kinds-of-invariants.md b/ralf/_posts/2018-08-22-two-kinds-of-invariants.md index 785a9fd..2e4ff31 100644 --- a/ralf/_posts/2018-08-22-two-kinds-of-invariants.md +++ b/ralf/_posts/2018-08-22-two-kinds-of-invariants.md @@ -102,6 +102,10 @@ But that's okay, because this is carefully controlled unsafe code -- and by the > *Unsafe code only has to uphold safety invariants at the boundaries to safe code.* +Notice that the "boundary" is not necessarily where the `unsafe` block ends. +The boundary occurs where the unsafe code provides a public API that safe code is intended to use -- that might be at the module boundary, or it might even be at the crate level. +That is where safe code should be able to rely on safety, so that it can interact with the unsafe code without triggering undefined behavior, and hence that is where the safety invariants come into play. + This is in strong contrast to validity, which must *always* hold. Layout optimizations and LLVM's attributes are in effect throughout unsafe code, so it is never okay to ever have invalid data. -- 2.30.2