offset_of! is unsound about remacs HOT 6 OPEN

@kazcw what is our alternative? How likely is this to fail in practice?

from remacs.

If it were just a matter of breaking rustc's invariants that might not be as bad, because rustc itself doesn't do a lot of wild optimizations; but it compiles to getelementptr inbounds { ... }, { ... }* null, ..., which is a trap value to LLVM, causing the subsequent ptrtoint to be UB, and leaving you at LLVM's mercy. LLVM's mercy tends to involve nasal demons.

In this case one option would be: instead of doing the address calculations using a hypothetical instance at NULL, use a real instance. Since this macro is only used with C structs, and Rust has no constraints on the value range of fields in C structs, the example value can be conjured with mem::zeroed. You could use a trivial trait to mark that the types it operates on can be zero-initialized safely, and then use the trait's method instead of ptr::null(). In release builds the example value will be optimized away.

from remacs.

Thank you for the explanation @kazcw that is very helpful.

from remacs.

Ok, let's try moving to https://github.com/Gilnaa/memoffset.
This does NOT fix the problem that @kazcw raises. However, it moves the problem of solving it out of our code base. They have ideas and are looking at using solutions from the RFC mentioned which has actually been more than partially implemented. Long term, there may end up being a supported macro from the Rust core and we drop the dependency. A pre-RFC exists for such a macro currently.

from remacs.

In that case I presume we need to replace the usage of offset_of! the field-offset crate in LispBufferRef::reset_local_variables as well? (I didn't realize we had our own macro when I imported that crate)

from remacs.

FWIW, the latest version of https://github.com/Gilnaa/memoffset actually works in a way that is compliant with the Rust Reference. :)

But doing * on a NULL pointer is still UB, even inside addr_of!.

from remacs.