Repository navigation
The offset_of! macro may need to be a compiler intrinsic #48956
Description
Activity
Existing crates implementing
offset_of:-
https://crates.io/crates/memoffset — Implemented using
mem::uninitialized(). Result: returns 0. -
https://crates.io/crates/field-offset — Implemented using
mem::zeroed(). Result: panic from its own sanity check.thread 'main' panicked at 'assertion failed: offset + mem::size_of::<U>() <= mem::size_of::<T>()'
(Also, there should be an
offset_of_val!in additional tooffset_of!due to DST field.)-
Why do we even need a memory location for that? Can't we just create a raw pointer from the ether and operate on that?
https://play.rust-lang.org/?gist=79229d888ce819235d5350241a037a78&version=stable
Perhaps! I recall some discussion in the past about how valid the temporary reference is there, but I'd naively assume that such a construction was reasonable!
I guess @rust-lang/lang would have to answer this, but I think the answer is "yes". We've had some things around this area like https://internals.rust-lang.org/t/pre-rfc-add-a-new-offset-of-macro-to-core-mem/9273
Given that we have had rust-lang/rfcs#3308 and now have the
offset_of!macro (#106655), I think this can be closed.
This came up a few weeks ago in libs triage specifically related to #48493 where we were wondering if there were other locations in the standard library that needed to be adjusted to handle uninhabited enums being handled in generic locations. While not many locations in the standard library leapt to mind one thing we thought of was the
offset_of!macro.For example if we've got something like:
do existing
offset_of!macros handle this?or is there "technical UB that rustc may paper over today" somewhere in there?
cc @dtolnay, I think you had better ideas about examples here than I!