Re: [WIP 0/3] Memory model and atomic API in Rust

[Boqun Feng <boqun.feng@gmail.com>]

On Wed, Mar 27, 2024 at 05:49:41PM -0400, Kent Overstreet wrote:
[...]
> > > Strict aliasing is crap in C and C++ because we started out with
> > > unrestricetd pointers, and it just doesn't work in C and C++ with the
> > > realities of the kind of code we have to write, and we never got any
> > > kind of a model that would have made it workable. Never mind trying to
> > > graft that onto existing codebases...
> > > 
> > > (Restrict was crap too... no scoping, nothing but a single f*cking
> > > keyword? Who ever thought _that_ was going to work?)
> > > 
> > > _But_: the lack of any aliasing guarantees means that writing through
> > > any pointer can invalidate practically anything, and this is a real
> > 
> > I don't know whether I'm 100% correct on this, but Rust has references,
> > so things like "you have a unique reference to a part of memory, no one
> > would touch it in the meanwhile" are represented by `&mut`, to get a
> > `&mut` from a raw pointer, you need unsafe, where programmers can
> > provide the reasoning of the safety of the accesses. More like "pointers
> > can alias anyone but references cannot" to me.
> 
> That's not really a workable rule because in practice every data
> structure has unsafe Rust underneath. Strict aliasing would mean that

I don't follow, a plain data structure like:

	struct Point { x: i64, y: i64 }

doesn't have any unsafe Rust underneath I think.

> unsafe Rust very much has to follow the aliasing rules too.
> 

The point I was trying to say, the aliasing rule on Rust raw pointers is 
relatively relaxed compared to strict aliasing in C since Rust has
references which should have more accurate informatio on aliasing.

(but not a language expert).

Regards,
Boqun