-
Notifications
You must be signed in to change notification settings - Fork 126
Description
Design
Option 1: Implement FromBytes
and IntoBytes
directly
See #170 for a detailed discussion.
We would need to ensure that pointer-to-int transmutations are sound, which is currently up in the air. Even with that settled, these would be a significant footgun because it would be easy to perform transmutes that don't preserve provenance, and thus create raw pointers which users expect to be able to soundly dereference, but actually can't.
Option 2: Separate support for provenance-carrying types
We could do something similar to Immutable
:
- Treat
FromBytes
andIntoBytes
as implicitly banning provenance - Split out a separate
ProvenanceFree
trait, and bound all existing transmutation methods with this trait - Permit implementing
ProvenanceFree
for everything that currently implementsFromBytes
andIntoBytes
With this scaffolding, we could add separate transmutation methods that do not require T: ProvenanceFree
, and use strict provenance APIs like with_exposed_provenance
to ensure that provenance is correctly handled.
Note that some APIs may not require this. For example, some uses of transmute!
would be sound without a T: ProvenanceFree
trait bound - e.g. transmuting from *mut T
to *mut U
might preserve provenance (although we would need to confirm this).
Option 3: Raw pointer wrapper types
Provide newtype wrappers around raw pointers which have getter methods that use strict provenance APIs like with_exposed_provenance
to ensure that provenance is correctly handled. These newtypes can implement FromBytes
and IntoBytes
.