Pointee not on the heap? [LWN.net]

Pointee not on the heap?

Posted Apr 23, 2026 8:08 UTC (Thu) by pbonzini (subscriber, #60935)
Parent article: One Sized trait does not fit all

The C side does have the definition and could return a pointer to a global variable for example, or even a "marker pointer" that is identified by its bit pattern rather than actually pointing to something. Are these supported, or can Pointee really be used on the heap only?

to post comments

Pointee not on the heap?

Posted Apr 23, 2026 11:43 UTC (Thu) by daroc (editor, #160859) [Link] (2 responses)

Oops — that's my mistake. Yes, you're right that C could return any kind of pointer it likes. Pointee is supposed to be completely opaque, so that should be fine.

Pointee not on the heap?

Posted Apr 23, 2026 13:42 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (1 responses)

Even if on the stack, C could pass it into a callback :)

Pointee not on the heap?

Posted Apr 23, 2026 14:19 UTC (Thu) by daroc (editor, #160859) [Link]

True! I guess the precise way of saying what's going on with Pointee is "it can't be used in any place that requires Rust code to have knowledge of its size, meaning that it can only be stored as the last element of (heap-allocated) Rust structures and must always be interacted with via a pointer of some kind, even if that is a fake 'pointer' invented by C code", but that doesn't really fit in the little summary table. So given the surrounding article for context, I'm comfortable summarizing those rules as "not on the stack". :)

Pointee not on the heap?

Posted Apr 23, 2026 17:21 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (3 responses)

I think Rust is already comfortable with pointers where we know nothing whatsoever about the thing pointed to. Indeed unlike C++ Rust is comfortable with raw pointers which are not valid, so e.g. if you want to store the integer 5, or the text 'CLOWNS' in this 64-bit CPU register which has the type of a raw pointer to a Doodad, Rust is OK with that existing *so long* as you have ensured you will never try to dereference the pointer in the Rust. If you dereference a nonsense pointer that's UB, which is why dereferencing raw pointers is one of the handful of named unsafe "super powers" - it's on the programmer to make sure they only do this to valid pointers.

I think the idea with Pointee is that we know that there is something pointed to, but Rust doesn't know what and so will never know (not at compile time, not at execution start, not even at runtime) how big Pointee is. So I think Pointee in some sense isn't a new addition to the model, but the current status quo for "We don't know the size".

Pointee not on the heap?

Posted Apr 23, 2026 19:07 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (2 responses)

I *think* the difference is that you can have a &Pointee that points to invalid memory because it's guaranteed that Rust code will never actually access the memory. This can only happen by passing it back to another language via FFI, and whoever creates the &Pointee ensures that whoever receives it won't produce undefined behavior.

Pointee not on the heap?

Posted Apr 23, 2026 19:43 UTC (Thu) by daroc (editor, #160859) [Link] (1 responses)

I guess I didn't explain this well enough; Pointee is a subset of the current category !Sized. So current Rust code does handle things that would be Pointee.

The point of the RFC is that !Sized is really lumping two separate, useful categories together: SizeOfVal (where we don't know the size based on the type, but we can know the size of some particular value) and Pointee (where we can't know the size at all).

Pointee not on the heap?

Posted Apr 23, 2026 21:22 UTC (Thu) by pbonzini (subscriber, #60935) [Link]

Yes, what I meant is that not knowing the size at all has interesting effects on what constitutes a valid value of a reference.