You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I have looked at your code to figure out how you dealt with provenance and I haven't been able to convince myself that Erased.specify will be called in a way that provenance is conserved. Would it be possible to better document this in the safety statements or change the impl of Erased to make sure it does not lose provenance?
I am not sure if the latter can be achieved with current stable rust, but #![feature(ptr_metadata)] with to_raw_parts and from_raw_parts_mut would make Erased itself track provenance without changing its API. The nightly feature is certainly not stable especially as the consider to change the result from to_raw_parts to be *const NewOpaqueType rather than *const () but it may make sense to change Erased impl based on a ptr_metadata feature flag
The text was updated successfully, but these errors were encountered:
You’re right in that Erased currently makes little effort to maintain pointer provenance. I took a look at doing it using those APIs, but the problem is that I had wanted to make the entire library usable on stable. For Sized types expose_provenance has been released, but we still don’t have access to the pointer metadata on stable. I’ll try to improve the documentation when I can, though.
Hi,
I have looked at your code to figure out how you dealt with provenance and I haven't been able to convince myself that Erased.specify will be called in a way that provenance is conserved. Would it be possible to better document this in the safety statements or change the impl of Erased to make sure it does not lose provenance?
I am not sure if the latter can be achieved with current stable rust, but
#![feature(ptr_metadata)]
with to_raw_parts and from_raw_parts_mut would make Erased itself track provenance without changing its API. The nightly feature is certainly not stable especially as the consider to change the result fromto_raw_parts
to be*const NewOpaqueType
rather than*const ()
but it may make sense to change Erased impl based on aptr_metadata
feature flagThe text was updated successfully, but these errors were encountered: