pub unsafe trait TryTransmuteFromPtr<Src: ?Sized, A: Aliasing, SV: Validity, DV: Validity, C: CastExact<Src, Self>, R> { }Expand description
Transmutations which are sound to attempt, conditional on validating the bit validity of the destination type.
If a Ptr transmutation is TryTransmuteFromPtr, then it is sound to
perform that transmutation so long as some additional mechanism is used to
validate that the referent is bit-valid for the destination type. That
validation mechanism could be a type bound (such as TransmuteFrom) or a
runtime validity check.
§Safety
§Post-conditions
Given Dst: TryTransmuteFromPtr<Src, A, SV, DV, C, _>, callers may assume
the following:
Given src: Ptr<'a, Src, (A, _, SV)>, if the referent of src is
DV-valid for Dst, then it is sound to transmute src into dst: Ptr<'a, Dst, (A, Unaligned, DV)> using C.
§Pre-conditions
Given src: Ptr<Src, (A, _, SV)> and dst: Ptr<Dst, (A, Unaligned, DV)>,
Dst: TryTransmuteFromPtr<Src, A, SV, DV, C, _> is sound if all of the
following hold:
- Forwards transmutation: Either of the following hold:
- So long as
dstis active, no mutation ofdst’s referent is allowed except viadstitself - The set of
DV-valid referents ofdstis a superset of the set ofSV-valid referents ofsrc(NOTE: this condition effectively bans shrinking or overwriting transmutes, which cannot satisfy this condition)
- So long as
- Reverse transmutation: Either of the following hold:
dstdoes not permit mutation of its referent- The set of
DV-valid referents ofdstis a subset of the set ofSV-valid referents ofsrc(NOTE: this condition effectively bans shrinking or overwriting transmutes, which cannot satisfy this condition)
- No safe code, given access to
srcanddst, can cause undefined behavior: Any of the following hold:AisExclusiveSrc: ImmutableandDst: Immutable- It is sound for shared code to operate on a
&Srcand&Dstwhich reference the same byte range at the same time
§Proof
Given:
src: Ptr<'a, Src, (A, _, SV)>src’s referent isDV-valid forDst
We are trying to prove that it is sound to perform a cast from src to a
dst: Ptr<'a, Dst, (A, Unaligned, DV)> using C. We need to prove that
such a cast does not violate any of src’s invariants, and that it
satisfies all invariants of the destination Ptr type.
First, by C: CastExact, src’s address is unchanged, so it still satisfies
its alignment. Since dst’s alignment is Unaligned, it trivially satisfies
its alignment.
Second, aliasing is either Exclusive or Shared:
- If it is
Exclusive, then bothsrcanddstsatisfyExclusivealiasing trivially: sincesrcanddsthave the same lifetime,srcis inaccessible so long asdstis alive, and no other livePtrs or references may reference the same referent. - If it is
Shared, then either:Src: ImmutableandDst: Immutable, and so neithersrcnordstpermit interior mutation.- It is explicitly sound for safe code to operate on a
&Srcand a&Dstpointing to the same byte range at the same time.
Third, src’s validity is satisfied. By invariant, src’s referent began
as an SV-valid Src. It is guaranteed to remain so, as either of the
following hold:
dstdoes not permit mutation of its referent.- The set of
DV-valid referents ofdstis a subset of the set ofSV-valid referents ofsrc. Thus, any value written viadstis guaranteed to be anSV-valid referent ofsrc.
Fourth, dst’s validity is satisfied. It is a given of this proof that the
referent is DV-valid for Dst. It is guaranteed to remain so, as either
of the following hold:
- So long as
dstis active, no mutation of the referent is allowed except viadstitself. - The set of
DV-valid referents ofdstis a superset of the set ofSV-valid referents ofsrc. Thus, any value written viasrcis guaranteed to be aDV-valid referent ofdst.
Dyn Compatibility§
This trait is not dyn compatible.
In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.