News for hackers. Stuff that matters.
Re:C and C++ Prioritize Performance over Correctness by LegionMammal978 on Friday August 18, 2023 @04:23PM (#37181590)
While standard C++ has no equivalent of a noalias annotation, it's wrong to say that it has no aliasing requirements. To access an object behind a pointer (or a glvalue in general), the type of the pointer must be (with a few exceptions) similar to the type of the pointee in memory, which is generally the object previously initialized at that pointer's address. This enables type-based alias analysis (TBAA) in the compiler, where if a pointer is accessed as one type, and another pointer is accessed as a dissimilar type, then the compiler can assume that the pointers don't alias.

Meanwhile, Rust ditches TBAA entirely, retaining only initialization state and pointer provenance in its memory model. It uses its noalias-based model to make up for the lack of type-based rules. I'd say that this is the right call from the user's standpoint, but it can definitely be seen as a tradeoff rather than an unqualified gain.

Re:C and C++ Prioritize Performance over Correctness by celeritascelery on Friday August 18, 2023 @08:21PM (#37184017)
Why couldn’t the Rust compiler also assume that dissimilar types don’t alias?
Re:C and C++ Prioritize Performance over Correctness by LegionMammal978 on Saturday August 19, 2023 @01:10PM (#37190859)
Because existing unsafe code written in stable Rust depends on the ability to convert raw pointers and references from one type to another, as long as their memory layouts match. That's the whole premise of the bytemuck crate [0], and it's the basis for things like the &str-to-&[u8] or &[u8]-to-&str conversions in the standard library.

[0] https://docs.rs/bytemuck/latest/bytemuck/