←back to thread

Tree Borrows

(plf.inf.ethz.ch)
565 points zdw | 4 comments | | HN request time: 0.89s | source
Show context
jcalvinowens ◴[] No.44513250[source]
> On the one hand, compilers would like to exploit the strong guarantees of the type system—particularly those pertaining to aliasing of pointers—in order to unlock powerful intraprocedural optimizations.

How true is this really?

Torvalds has argued for a long time that strict aliasing rules in C are more trouble than they're worth, I find his arguments compelling. Here's one of many examples: https://lore.kernel.org/all/CAHk-=wgq1DvgNVoodk7JKc6BuU1m9Un... (the entire thread worth reading if you find this sort of thing interesting)

Is Rust somehow fundamentally different? Based on limited experience, it seems not (at least, when unsafe is involved...).

replies(11): >>44513333 #>>44513357 #>>44513452 #>>44513468 #>>44513936 #>>44514234 #>>44514867 #>>44514904 #>>44516742 #>>44516860 #>>44517860 #
1. steveklabnik ◴[] No.44513452[source]
While both involve aliasing, C's strict aliasing and Rust's aliasing are two different things. Rust pretty explicitly did not adopt the C style.

C's aliasing is based on type alone, hence its other name "type based alias analysis" or TBAA.

replies(1): >>44517331 #
2. gronpi ◴[] No.44517331[source]
And TBAA is much easier for programmers to wrangle than the aliasing of Rust, right? The corresponding aliasing feature for C would be _restrict_, which is rarely used.

Though Linus and Linux turns off even strict aliasing/TBAA.

replies(1): >>44518406 #
3. simonask ◴[] No.44518406[source]
I don't think TBAA is easier to wrangle at all, or rather, it's almost never relevant except for allowing the compiler to make obviously, trivially true assumptions. Without it (all pointers could alias all the time), any C function taking more than one pointer argument would compile to a very surprising series of instructions, reloading from memory every single time any pointer is dereferenced.

Rust's rules are very simple and easy to get right - not least because breaking them is a compiler error.

replies(1): >>44518543 #
4. hamcocar ◴[] No.44518543{3}[source]
Hmmm.

How is your comment consistent with some C compilers enabling users to disable TBAA/strict aliasing? Like the Linux kernel does. Do those codebases fit "compile to a very surprising series of instructions,"?