Conform with strict provenance

[GoldsteinE]

Previous version stored pointer as a usize, which causes warnings in Miri by default and error with -Zmiri-strict-provenance.

This version stores pointer directly and allows using proper strict provenance APIs with sptr feature. It potentially benefits optimizations and clarifies semantics of pointer-to-integer casts.

This PR also rewrites a couple of Clone implementations to be defined in terms of Copy.

Unfortunately, doing this introduced some semver-incompatible changes to the API:

• pack() now returns a *mut T instead of usize
• unpack() now takes a *mut T instead of usize

Considering this, I’m not sure whether it would be worthwhile to merge. Maybe adding new pack_ptr() / unpack_ptr() functions would work better?

[jjl]

hey, thanks for the PR. it's good timing because i was looking at strict provenance for this the other week

i'm at a bit of a crossroads for what to do with this library to be honest. basically every time i go to use it it's not actually suitable because i want to do something it can't handle like either be a pointer or an integer depending n the value of a tag bit.

so i end up copying and pasting the packing and unpacking functions into another project and removing the bits i don't need...

ideas welcome :)

[GoldsteinE]

something it can't handle like either be a pointer or an integer depending n the value of a tag bit

I think this logic is pretty easily implementable with something like extension trait? Am I missing something?

[jjl]

something it can't handle like either be a pointer or an integer depending n the value of a tag bit

I think this logic is pretty easily implementable with something like extension trait? Am I missing something?

i didn't immediately see a nice way to represent such shenanigans. i'm open to ideas if you have some though.

[GoldsteinE]

What’s the goal? To have a method to extract either a pointer or an integer depending on the tag value, something like

pub enum Kind { Ptr, Num }
pub fn extract(self, f: impl Fn(usize) -> Kind) -> Either<*mut T, usize>;

?

[GoldsteinE]

Or just bool instead of a Kind maybe

[jjl]

oh. yes, i considered something like that, but i just don't think it's very nice.

but more generally, i find ointers wanting every time i come to use it and i think there's got to be a better overall design that takes things like these into account.

[jjl]

i haven't come up with a magic better option, so let's go with it

[jjl]

4.0.1 shipped to crates

[GoldsteinE]

Thanks! I’m not sure 4.0.1 is a right increment though — pack() and unpack() APIs changed, so that’s a breaking change.

[jjl]

you're the only person to ever file an issue or open a PR here, i doubt it'll ruin anyone's day :shrug: