Rust 1.77.0 released

As I understand it, the basic problem is that Rust's & operator gets you a reference, not a raw pointer. A raw pointer is basically like a C pointer; it doesn't really make any promises about pointing anywhere useful. A reference is in memory just a pointer too, but the semantics are different and basically the biggest thing that makes Rust special: it's a guarantee that the thing it points to is valid (has not yet been deallocated/freed) and that at any given time there is either at most one non-const (&mut) reference or that all references are const. The obvious / conventional way to implement offset_of is to make a null pointer of type pointer to the struct in question, index into the field in question, take its address, and return as an integer (see e.g. the most recent C implementation in Linux). But if you implement this in Rust, even if you start with a raw null pointer 0 as *const Foo, indexing into a field and taking the address gets you a reference, not a null pointer - and it is a thoroughly invalid reference, and so it is undefined behavior.

The implementation of addr_of! uses the syntax &raw (which is not yet available in stable Rust, but the standard library can use it), which immediately creates a raw pointer, not a reference, avoiding the undefined behavior.

The other approach is to start with an actual object (or just a reference to one), which gives you no trouble constructing a real reference to one of its members. But that requires the object to exist. You can't necessarily create an object of an arbitrary type; you may have to call its constructor, which might not be possible without an unwanted side effect (consider std::fs::File or std::process::Child). There was a prior issue in that same third-party crate due to creating a reference to an object that was not properly constructed, though resolving this issue did not by itself remove all the UB in that crate.

(Also, it took me about an hour to come up with this comment and be at least somewhat confident it was correct - I had previously written out a totally different analysis based on misunderstanding the validity of raw pointers themselves - which is by itself another good reason that this should be encapsulated in some super obvious standard library facility instead of expecting people to get it correct on their own, even if technically they could.)