Skip to content

Do ZST Boxes violate provenance monotonicity? #529

Closed
rust-lang/rust
#129748
@joshlf

Description

@joshlf

(Writing on my phone; apologies for the lack of formatting.)

Per the Box module-level docs:

For zero-sized values, the Box pointer still has to be valid for reads and writes and sufficiently aligned. In particular, casting any aligned non-zero integer literal to a raw pointer produces a valid pointer, but a pointer pointing into previously allocated memory that since got freed is not valid. The recommended way to build a Box to a ZST if Box::new cannot be used is to use ptr::NonNull::dangling.

I'm trying to interpret "pointer pointing into previously allocated memory." IIUC, an integer whose address is the same as previously-allocated memory should be fine, so what really distinguishes these two cases is whether or not the pointer in question has provenance for the previously-freed allocation.

However, this implies that Box violates provenance monotonicity: an operation with a provenance-free pointer (one cast from a bare integer) is sound, while the same operation with a provenance-carrying integer is not.

Am I understanding this correctly?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions