Document raw pointer <-> usize casts.

[ben0x539]

No description provided.

[ben0x539]

I was advised that these casts are controversial (and to cc @RalfJung), but I think promising at minimum something like this is necessary to describe how people use raw pointers right now irl.

[RalfJung]

I'm afraid "same value" is impossible since pointers carry provenance that is inadvertently lost on an integer roundtrip. See this blog post for the kind of issues that arise when one assumes that a ptr-int-ptr roundtrip returns the same value.

So it might be a different value, but it will point to the same location ("numeric address", I guess).

[ben0x539]

C++ seems to use similar phrasing: https://eel.is/c++draft/expr.reinterpret.cast#5

Is the description of the as operation the best place to get into the details of how provenance work? What are we willing to stabilize about as?

[RalfJung]

C++ seems to use similar phrasing

Yeah, and C/C++ are notoriously bad at documenting how pointers behave, which leads to the kinds of problems I have described in my blog post. I view C and C++ as bad examples in this regard, not as something we should copy. I think Rust can and should do better here. (C is in the process of improving; I hope C++ will follow eventually.)

What are we willing to stabilize about as?

I could agree to saying something like

Casting from usize to a raw pointer will produce a pointer pointing to the same location as the original pointer if the usize was obtained through a pointer to address cast of a valid pointer.

(I removed "of the same type" since it is not relevant in Rust.) I'd prefer to explicitly talk about provenance, and I think a basic understanding of provenance is required to properly work with int-ptr-casts, but I don't have time to draft all that text right now. It might be worth to at least explicitly state that "two pointers point to the same location" does not imply that the two pointers have the same value, i.e., to explicitly say that there's more to a pointer than the location it points to. I am also not sure if "location" is the best term and am open to suggestions for other terms to use here.

[Havvy]

We don't actually discuss provenance anywhere in the reference currently. It'd be part of the memory model, but uhh, we've avoided that area. I'm not actually sure we want to talk about it here. cc @RalfJung against for what they think.

I'm mostly giving stylistic nits here, and you should wait on Ralf before applying them since he might give better non-stylstic review.

[ben0x539]

Thanks for the stylistic pointers!

I also don't want to put a discussion of the memory model into the "what does a cast do" section, but I definitely don't want to trick readers into thinking it's easier than it is. Since a lot of it isn't entirely hammered out as far as I understand, I just wanted to get the basics written down.

[RalfJung]

We don't actually discuss provenance anywhere in the reference currently. It'd be part of the memory model, but uhh, we've avoided that area. I'm not actually sure we want to talk about it here. cc @RalfJung against for what they think.

I think this needs a decision from @rust-lang/lang.^^ I cannot make the call here, all I can say is whether a proposed spec is consistent with what I know about how to mathematically formalize ptr-int-casts and pointer provenance, and I can help flesh out the formulation.

[Havvy]

Nominating as per the previous comment.

[nikomatsakis]

We discussed this in our 2021-04-06 meeting. The consensus in that meeting was that we did not want to merge this PR, because we didn't feel ready to make commitments one way or the other on this question. It seems like making statements about provenance would be best done when we've worked out more of the stack borrows story etc.

We would however be interested in having a design meeting to talk about the overall plan forward regarding provenance, correct pointer usage, etc.

[nikomatsakis]

(We'd be inclined to close this PR, as a result)

[ben0x539]

This PR wasn't meant to be about provenance. Currently there seems to be no official documentation or specification about what pointer<->usize casts do at all. Provenance wording happened because "you obviously just get the same pointer back if you go back and forth" was too ambitious, but of course I would be happy to write down something much weaker.

Is there any behavior, wording aside, that we'd be happy to commit to right now, or would you prefer to leave pointer<->usize casts completely undefined until the provenance/stacked borrows thing is fully hashed out?

[nikomatsakis]

Hmm, I think it would be useful to document them! I imagine something that leaves a lot of open-ended would work. Something like this?

• Casting from a pointer to an integer produces the machine address. Note that this interacts with the Rust model which is still under development; casting from a pointer to an integer and back may or may not be equivalent depending on the results of that work.

[ben0x539]

Great, I'll amend this PR!

I think it may be good to include some basically "blessed" examples of roundtrips that don't go anywhere near the tricky cases, but the table/list-based structure of this section makes it a bit awkward. hm.

[ben0x539]

ok so this also changes the formatting a bunch, breaking up the big nested list into sections with headings, so that I could fit in an example.

The actual wording should not be overreaching, I hope.

[nikomatsakis]

This is looking much better to me, modulo @RalfJung's nits.

[RalfJung]

My comments have been resolved.
I can't approve or merge PRs in this repo.

[ehuss]

Approving per nikomatsakis and RalfJung.

I pushed a small change to change a link to markdown.

Thanks!

was resolved