Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provenance and Erased #20

Open
sirati opened this issue Mar 9, 2025 · 1 comment
Open

Provenance and Erased #20

sirati opened this issue Mar 9, 2025 · 1 comment

Comments

@sirati
Copy link

sirati commented Mar 9, 2025

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

@claytonwramsey
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants