[Change]: A pointer in a const does not need to be non-dangling

[inkreasing]

Change description

Currently the fls states that a pointer in a const shall be non-dangling. The compiler accepts a raw dangling pointers in constants.

Area

const evaluation

Category

Bug

FLS Paragraph ID

ls_l1FOH8zt0XRZ

Change description (extended)

fn main() {
    // accepted by the compiler
    const A: *const u8 = std::ptr::dangling();
    const B: *const u8 = std::ptr::null();
    // not accepted by the compiler    
    //const C: &u8 = unsafe { &(*std::ptr::dangling()) };
}

This creates a dangling pointer.
Maybe the text should be changed to say reference instead of pointer?

(i am sorry if i misunderstood the use of "shall". I looked at 1.3.5 and it seems to me that shall is used for rules that the programmer has to follow either to make the compiler accept the program or to avoid UB. But this is both accepted by the compiler and not UB.)

[kirtchev-adacore]

Hi @inkreasing ! Thank you for the report.

We (the FLS team) had discussed a similar case to what you pointed out, and most likely botched the wording (I in particular). Here is the example I have been playing with:

struct Ptr {
    field: *const u8,
}
struct Ref<'a> {
    field: &'a u8,
}
fn main() {
    // accepted by the compiler
    const A: *const u8 = std::ptr::dangling();
    const B: *const u8 = std::ptr::null();
    
    // not accepted by the compiler
    // memory access failed: attempting to access 1 byte, but got 0x1[noalloc] which is a dangling pointer (it has no provenance)
    const C: &u8 = &(unsafe { *std::ptr::dangling() });
    
    // constructing invalid value of type &u8: encountered a dangling reference (0x1[noalloc] has no provenance)
    const D: &u8 = unsafe { &(*std::ptr::dangling()) };
    
    // constructing invalid value of type &u8: encountered a null reference
    const E: &u8 = &(unsafe { *std::ptr::null() });

    // constructing invalid value of type &u8: encountered a null reference
    const F: &u8 = unsafe { &(*std::ptr::null()) };

    // constructing invalid value of type Ref<'_>: at .field, encountered a dangling reference (0x1[noalloc] has no provenance)
    const G: Ref = Ref { field: unsafe { &(*std::ptr::dangling()) }};

    // encountered dangling pointer in final value of constant
    const H: *const u8 = { let x = 0u8; &raw const x };

    // encountered dangling pointer in final value of constant
    const I: Ptr = Ptr { field: { let x = 0u8; &raw const x } };
}

Case C and D are covered by fls_9wgldua1u8yt: "It is undefined behavior to dereference a raw pointer that is either dangling or unaligned.", where we have defined dangling as "A value of an indirection type is dangling if it is either null or not all of the bytes at the referred memory location are part of the same allocation.". (Replace "indirection type" by "pointer type", this will be changed soon-ish)

Cases E and F are covered by fls_ezh8aq6fmdvz: "It is a validity invariant for a value of a reference type to be not null".

For case G, I suspect that we will have to update fls_ezh8aq6fmdvz to "It is a validity invariant for a value of a reference type to be non-dangling", and then update the definition of "dangling" to include the lack of provenance (since this is what std::ptr::dangling() creates).

For H and I, as Pete had stated "a provenance-carrying pointer in the final value must not point to an allocation freed during evaluation", which we will need to turn into some kind of rule. I suspect that this observation is actually subsumed by the semantics of provenance, especially "the timespan during which the accesses may occur". Basically a pointer no longer has provenance over a deallocated memory location. Perhaps this will just fall out from the redefinition of "dangling" to include lack of provenance... I will have to discuss this with the FLS team.

[inkreasing]

Example I and H are very interesting, thank you!

static A: u8 = 10;

const B: *const u8 = unsafe {(&raw const A).wrapping_add(10)};

This compiles, even though it has invalid provenance to the location it points to. If you do a provenance base explanation you might need to distinguish between those two cases.

I think a lot can be explained by the implementation (although this is not useful for the FLS). The compiler needs to create the const allocations that are pointed to and when the pointer has no provenance it is easy (just create no allocation), but when the pointer has invalid provenance the assumption is probably that the user intended there to be something, so it's better to error. In the example above it is also easy, since there already is an allocation for the static. If const alloc is stabilised it will be interesting to see, if returning a out of bounds pointer with otherwise complete provenance to a live const allocation is allowed.

and then update the definition of "dangling" to include the lack of provenance (since this is what std::ptr::dangling() creates).

But then the classic case of a dangling pointer (you free an allocation and now the pointer to it is dangling) it not dangling anymore, since it does not have no provenance, it has invalid provenance. In regular code invalid provenance and no provenance are the same, but in const evaluation apparently they are not the same.

I always assumed "non-dangling" to mean "dereferencable". Not necessarily with a typed read, but with a untyped read of the size of the pointed to type. This would include provenance to the allocation at the address.