From f0ea07bf1f64acbe93088bbdf5ebf7284c389855 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Thu, 23 Aug 2018 12:34:29 +0200 Subject: [PATCH 1/1] clarify validity for prtially initialized local variables --- personal/_posts/2018-08-22-two-kinds-of-invariants.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/personal/_posts/2018-08-22-two-kinds-of-invariants.md b/personal/_posts/2018-08-22-two-kinds-of-invariants.md index 2e4ff31..c54a010 100644 --- a/personal/_posts/2018-08-22-two-kinds-of-invariants.md +++ b/personal/_posts/2018-08-22-two-kinds-of-invariants.md @@ -108,10 +108,11 @@ That is where safe code should be able to rely on safety, so that it can interac 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. +(With the sole restriction of data which *the compiler statically knows is not initialized*: If you write `let b: bool;`, that data in `b` is kept inaccessible *even to unsafe code*, and it does not have to satisfy any invariant. This works because the compiler knows about `b` not being initialized.) > *Unsafe code must always uphold validity invariants.* -So we clearly cannot just pick the same invariant for both. +So we clearly cannot just pick the same invariant for both, or else it would be impossible to write `Vec`. We *might* want to just ignore user-defined invariants when it comes to validity, but I think that would be ill-advised. First of all, validity is part of the definition of undefined behavior. -- 2.30.2