transmute: caution against int2ptr transmutation

[RalfJung]

This came up in #121282.
Cc @saethlin @scottmcm

Eventually we'll add a proper description of provenance that we can reference, but that's a bunch of work and it's unclear who will have the time to do that when. Meanwhile, let's at least do what we can without mentioning provenance explicitly.

[rustbot]

r? @m-ou-se

rustbot has assigned @m-ou-se.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[m-ou-se]

r=me

[RalfJung]

@scottmcm should this go through t-lang FCP?

[saethlin]

I would prefer to see something here that indicates that it is specifically not possible to round-trip pointers through transmuting to an integer type and back, because that is the pattern that people do in the wild.

[workingjubilee]

I would consider this an inevitable conclusion from the Provenance RFC's acceptance (i.e. not requiring FCP).

[RalfJung]

I would prefer to see something here that indicates that it is specifically not possible to round-trip pointers through transmuting to an integer type and back, because that is the pattern that people do in the wild.

This is currently implied by:

Doing non-zero-sized memory accesses with a pointer constructed this way [i.e., via transmutation] is currently considered undefined behavior.

Are you saying that roundtrips should be mentioned more explicitly? Sure, I can do that.

[RalfJung]

I would consider this an inevitable conclusion from the Provenance RFC's acceptance.

We could declare that ptr2int transmute "exposes" the pointer and int2ptr transmute makes it pick up an exposed provenance similar to as casts. This isn't really practical for union field accesses or raw pointer loads, but for transmute we know pretty well what happens and could add a special hack to the semantics.

I'd prefer if we didn't do that, though.

[workingjubilee]

If "transmute is semantically equivalent to a bitwise move of one type into another", then how would we rationalize the operation being different from a pointer load without changing the definition of transmute?

[RalfJung]

We'd rationalize this as a hack in the transmute intrinsic that is intended to keep old code working -- code that made wrong assumptions about the Rust memory model at a time when there were no reliable docs about which assumptions one could make.

transmute() would not be equivalent to "do a raw ptr store at one type and then raw ptr load at a different type" any more.

[workingjubilee]

Ah, we'd burn down the performance of Rust programs because they did undefined behavior! I see, I see.

Wait, what?

[RalfJung]

I don't think this would impact the performance of any "good" programs. After all with transmute we know exactly from which type to which type we are promoting.

I didn't say it's an option I like, I just said it's a possible option and the docs added here are not an inevitable conclusion of Rust having provenance on pointers but not integers.

[workingjubilee]

I suppose I can concede that much, and will simply say that I would strongly prefer we not seriously entertain any ideas that are technically valid but involve deeply undermining an understanding of how programs will be compiled.

[saethlin]

I believe Ralf is referring to reverting #121282. Before that PR, usize as ptr and transmute::<usize, ptr> have the same lowering. Such a change would primarily impact the codegen of programs using ptr::without_provenance, but we could always recoup that by resurrecting #121242 (which special-cases that function instead of giving it the naive transmute implementation).

[scottmcm]

should this go through t-lang FCP?

I brought this up briefly in lang triage today, @RalfJung. Meeting consensus was that we don't need checkboxes for it. If you/opsem are happy with the description, we're happy to land stuff since the RFC about having provenance was approved.

[RalfJung]

Okay let's do t-opsem FCP then.

@rustbot fcp merge

[RalfJung]

Oh, wrong bot.
@rfcbot fcp merge

[rfcbot]

Team member @RalfJung has proposed to merge this. The next step is review by the rest of the tagged team members:

• @CAD97
• @JakobDegen
• @RalfJung
• @digama0
• @saethlin

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[RalfJung]

@bors r=m-ou-se rollup
(source)

[bors]

📌 Commit f4adb1e has been approved by m-ou-se

It is now in the queue for this repository.