std::pointer::Nonnull should guarantee ABI compatibility for non-null pointer values

[jacobsa]

Can we rely on NonNull<T> having the same representation as *mut T for all non-null values of that type? In particular, can we rely on e.g. NonNull<std::ffi::c_void> being ABI compatible with C void* for non-null pointers?

It seems pretty likely that this should work, but the documentation doesn't guarantee it as far as I can see. The representation documentation for Nonnull only says that an extra byte won't be used for the discriminant in Option<Nonnull<T>>.

[hanna-kruppe]

ABI compatibility between NonNull and raw pointer types is guaranteed in Rust but note that this notion of ABI compatibility is (1) about type punning function pointers and (2) doesn’t apply to FFI:

Nothing in this section should be taken as a guarantee for non-Rust-to-Rust calls, even with types from core::ffi or libc.

Even this notion of “allowed fn signature mismatch” is arguably a mistake and probably won’t be extended as-is (see #140803). I’d advice against trying to rely on fn pointer type punning.

Memory layout is a separate question, e.g., on many platforms u32 and f32 have the same layout but are passed/returned in different registers. For NonNull vs raw, size and align and interpretation of the bytes should be the same. I don’t think there’s any realistic wiggle room for spurious differences. I don’t know if there’s an existing guarantee in docs that would imply this, though.

[jacobsa]

Thanks for the quick response. Yeah, sorry, I’m speaking specifically of memory layout here. I agree it wouldn’t realistically differ, but I couldn’t find any guarantee in the docs.

[asquared31415]

NonNull is #[repr(transparent)] around its inner pointer, and the inner pointer is private only to uphold its invariant, rather than as a private implementation detail.

I wonder if there's a design space here for rustdoc to show that, or if types should just document that explicitly.

[hanna-kruppe]

repr(transparent) is only useful for documenting a layout guarantee if the underlying field type is also guaranteed. But NonNull’s current field type (*const T) very much isn’t guaranteed: it only works due to the #[rustc_layout_scalar_valid_range_start(1)] attribute, which will probably be removed in favor of using pattern types for the fields that get extra niches (see #136006), and pattern types don’t even exist in stable Rust for the foreseeable future, so there’s no stable guarantee about their layout either.

[zachs18]

The docs for NonNull do guarantee that "Option<NonNull<T>> has the same size as *mut T" (link) ¹, but don't explicitly mention alignment for that guarantee (or ABI-compatibility).

Footnotes

1. by std::option's docs (link) guaranteeing that Option<NonNull<T>> and NonNull<T> have the same size (and alignment), we can thus conclude that NonNull<T> and *mut T have the same size. ↩

[jacobsa]

Yep, I found that documentation useful. Looking for a similarly useful sentence for this other aspect. :-)