Validity of references: Bit-related properties

[RalfJung]

Discussing the "bit-pattern validity" of references: the part that can be defined without referring to memory.

Certainly, references are non-NULL. Following the current lowering to LLVM, they also must be aligned. This is in conflict with creating references to fields of packed structs, see RFC 2582 for a proposed solution.

Do we want to allow uninitialized bits? Theoretically we could allow something like 0xUU000001 (on 32bit, where U represents 4 uninitialized bits) for &(), but there seems to be little point in doing so.

[RalfJung]

What does "aligned" mean for unsized types, where we might have to use the metadata to actually determine the alignment? For unsized types, the "actual" alignment isn't just a bit-level property. But we still have a "least required alignment" (whatever layout.align says for such types), and we could just use that?

For, &(u32, dyn Trait) would have to be 4-aligned if we just look at bit-related properties, even though the actual type implementing Trait could make higher requirements.

[nikomatsakis]

Certainly, references are non-NULL. Following the current lowering to LLVM, they also must be aligned.

Yes.

Do we want to allow uninitialized bits?

Absent a compelling reason to do so, I think we should forbid them for now.

[RalfJung]

Also see prior discussion at rust-lang/rust-memory-model#10 and rust-lang/rust-memory-model#12.

[the8472]

Summary from #77 (comment) and previous comments:

On some platforms (e.g. x86_64-unknown-linux-gnu) virtual address space available to userspace is limited such that several of the high bits will always be zero. Where exactly that limit is is a bit fuzzy due to advancements in processor technology and kernel features (sysv ABI and kernel documentation say 47bits for backwards compatibility, anything higher is opt-in), but saying that the upper half belongs to the kernel should be fairly conservative and forwards-compatible. So applying a platform-specific restriction to the bit patterns of references could make an additional 2^63 niche values available.
These niches would be much easier to use compared to alignment-based ones since they do not depend on the pointee type.

The only open question here is if this could also be applied to &ZST since they're not subject to virtual address space limitations, i.e. if there's anything safe today that would generate references to ZSTs that are > isize::MAX. #102 seems relevant.

[RalfJung]

The only open question here is if this could also be applied to &ZST since they're not subject to virtual address space limitations, i.e. if there's anything safe today that would generate references to ZSTs that are > isize::MAX.

I am not sure about "anything safe", but as of right now, the following code is certainly sound, so your proposal would be a breaking change:

fn mk_unit() -> &'static () { unsafe {
  &*(usize::MAX as *const ())
} }