From b229190aabab3130112ed8b20935647b3a87ebbd Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Sat, 3 Jun 2023 11:06:44 +0200 Subject: [PATCH] add link to more background on UnsafeCell --- personal/_posts/2023-06-02-tree-borrows.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/personal/_posts/2023-06-02-tree-borrows.md b/personal/_posts/2023-06-02-tree-borrows.md index 22dc754..8c82a20 100644 --- a/personal/_posts/2023-06-02-tree-borrows.md +++ b/personal/_posts/2023-06-02-tree-borrows.md @@ -155,7 +155,7 @@ More controversially, TB also changes how precisely things become read-only when In particular, for `&(i32, Cell)`, TB allows mutating *both* fields, including the first field which is a regular `i32`, since it just treats the entire reference as "this allows aliasing".[^1] In contrast, SB actually figured out that the first 4 bytes are read-only and only the last 4 bytes allow mutation via aliased pointers. -[^1]: This does not mean that we bless such mutation! It just means that the compiler cannot use immutability of the first field for its optimizations. Basically, immutability of that field becomes a [safety invariant instead of a validity invariant]({% post_url 2018-08-22-two-kinds-of-invariants %}): when you call foreign code, you can still rely on it not mutating that field, but within the privacy of your own code you are allowed to mutate it. +[^1]: This does not mean that we bless such mutation! It just means that the compiler cannot use immutability of the first field for its optimizations. Basically, immutability of that field becomes a [safety invariant instead of a validity invariant]({% post_url 2018-08-22-two-kinds-of-invariants %}): when you call foreign code, you can still rely on it not mutating that field, but within the privacy of your own code you are allowed to mutate it. See [my response here](https://www.reddit.com/r/rust/comments/13y8a9b/comment/jmlvgun/) for some more background. The reason for this design decision is that the general philosophy with TB was to err on the side of allowing more code, having less UB (which is the opposite direction than what I used with SB). This is a deliberate choice to uncover as much of the design space as we can with these two models. -- 2.30.2