| Crates.io | rel-ptr |
| lib.rs | rel-ptr |
| version | 0.2.3 |
| created_at | 2019-03-11 00:06:36.347208+00 |
| updated_at | 2019-04-12 00:16:15.770946+00 |
| description | A tool for building movable self-referential types |
| homepage | |
| repository | https://github.com/KrishnaSannasi/rel-ptr |
| max_upload_size | |
| id | 119965 |
| size | 40,971 |
rel-ptr a library for relative pointers, which can be used to create
moveable self-referential types. This library was inspired by
Johnathan Blow's work on Jai, where he added relative pointers
as a primitive into Jai.
A relative pointer is a pointer that uses an offset and it's current location to calculate where it points to.
Minimum Rust Version = 1.34.0
See the RelPtr type docs for safety information
no_stdThis crate is no-std compatible, simply add the feature no_std to move into no_std mode.
with nightly you get the ability to use trait objects with relative pointers
take the memory segment below
[.., 0x3a, 0x10, 0x02, 0xe4, 0x2b ..]
where 0x3a has the address 0xff304050 (32-bit system)
then 0x2b has the address 0xff304054.
if we have a 1-byte relative pointer (RelPtr<_, i8>)
at the address 0xff304052, then that relative pointer points to
0x2b as well, this is because its address 0xff304052, plus its
offset, 0x02 points to 0x2b.
There are three interesting things about this
The third point is what makes moveable self-referential structs possible
The type RelPtr<T, I> is a relative pointer. T is what it points to,
and I is what it uses to store its offset. In practice you can ignore I,
which is defaulted to isize, because that will cover all of your cases for using
relative pointers. But if you want to optimize the size of the pointer, you can use
any type that implements Delta. Some types from std that do so are:
i8, i16, i32, i64, i128, and isize. Note that the trade off is that as you
decrease the size of the offset, you decrease the range to which you can point to.
isize will cover at least half of addressable memory, so it should work unless you do
something really crazy. For self-referential structs use a type whose max value is atleast
as big as your struct. i.e. std::mem::size_of::<T>() <= I::max_value().
Note on usized types: these are harder to get working
struct SelfRef {
value: (String, u32),
ptr: RelPtr<String, i8>
}
impl SelfRef {
pub fn new(s: String, i: u32) -> Self {
let mut this = Self {
value: (s, i),
ptr: RelPtr::null()
};
this.ptr.set(&mut this.value.0).unwrap();
this
}
pub fn fst(&self) -> &str {
unsafe { self.ptr.as_ref_unchecked() }
}
pub fn snd(&self) -> u32 {
self.value.1
}
}
let s = SelfRef::new("Hello World".into(), 10);
assert_eq!(s.fst(), "Hello World");
assert_eq!(s.snd(), 10);
let s = Box::new(s); // force a move, note: relative pointers even work on the heap
assert_eq!(s.fst(), "Hello World");
assert_eq!(s.snd(), 10);
This example is contrived, and only useful as an example. In this example, we can see a few important parts to safe moveable self-referential types, lets walk through them.
First, the definition of SelfRef, it contains a value and a relative pointer, the relative pointer that will point into the tuple inside of SelfRef.value to the String. There are no lifetimes involved because they would either make SelfRef immovable, or they could not be resolved correctly.
We see a pattern inside of SelfRef::new, first create the object, and use the sentinel RelPtr::null() and immediately afterwards assigning it a value using RelPtr::set and unwraping the result. This unwrapping is get quick feedback on whether or not the pointer was set, if it wasn't set then we can increase the size of the offset and resolve that.
Once the pointer is set, moving the struct is still safe because it is using a relative pointer, so it doesn't matter where it is, only it's offset from its pointee.
In SelfRef::fst we use RelPtr::as_ref_unchecked because it is impossible to invalidate the pointer. It is impossible because we cannot
set the relative pointer directly, and we cannot change the offsets of the fields of SelfRef after the relative pointer is set.
NonZero* out of nightly due to rustc version 1.34.0unreachable
std::hint::unreachable, also it is safer to use the std version because std version is guarenteed to be optimized awayNullable and how it plays with DeltaFixed mutability bug, getting a raw ptr (*mut T) or a non-nullable ptr (NonNull<T>) should require a unique lock on RelPtr
TraitObject, now there is from_ref and from_mut to allow easier transitions to and from TraitObjectDefault bound for MetaData::Data
MetaData::Data before the relative pointer is setTraitObject::new in favor of the new constructorsMetaData::decompose
MetaData::data, the pointer can be extracted via pointer casts, so only data was neededMetaData to use std::mem::NonNull as it is easier to work with
Option<NonNull<T>> allows representing null even if T: !SizedI am not anticipating any more large scale changes to the api, so this should be as the final api. I will wait and see if any there are any bugs, before releasing 1.0.0. I will also have to wait on the results of this github discussion around the layouts of types, as it relates to how safe this model of moveable self-referential types are.
NonZero* integersRelPtr whose idicies support formattingConverted api to use &mut T instead of &T
RelPtr and was suggested by YandrosMoved Delta::ZERO to Nullable::NULL
NonZero* typesUpdated documentation to better explain possible UB
Changed from TraitObject::into to TraitObject::as_ref and TraitObject::as_mut