Do any languages have a notion of "relative pointers"? So in the example if instead of appending "line" as ptr & len, it'd instead be appending an offset & len which could in theory be used to safely compute the actual location even with relocations.
I made a mini example in C.
It's awkward to do get right because you need an indirect pointer whose address remains fixed, but points to another pointer which can change (and is volatile).
While it might be possible to make something like this lockless - it's much simpler to stick a mutex in the array header. When we access the array_segment we can take a lock to prevent some other thread reallocating mid-way through accessing.
There's probably a few improvements that could be made. In particular it doesn't handle use-after-free, so it's not thread safe w.r.t cleanup.
https://godbolt.org/z/rYzn5KGre
Languages with dependent types can express things like “this offset is in bounds relative to this other array”, which is maybe what you’re thinking of.
That is called an index. If you want it to be standalone, you can bundle it with the ArrayList.
I think parent was after base+offset+index rather than just base+index.
Examples would be eg, `string_view` or `ArraySegment`. They hold some offset relative to a base allocation, and when we index the string_view or ArraySegment we're indexing relative to that offset.
I wish languages made it easier (or possible) to track index ownership at compile time.
You can in Rust! You just bundle it with a lifetime.
But... This loses the reason people are using indices to begin with: because the borrow checker cannot track what they do.
If you squeeze your eyes a bit, C compilers for Windows used to have them, with far pointers (https://en.wikipedia.org/wiki/Far_pointer)
Similarly, CPU architectures that use descriptors can (have to?) have languages with that notion.
The FS and GS segment selectors are still used in x86-64, typically for `thread_local` storage, but they can be repurposed.
`thread_local` is an example of a "relative pointer" though. Instructions to access the thread local are prefixed with `fs:` or `gs:`, and point relative to the address in the respective segment register.
After more searching I found this article https://www.gingerbill.org/article/2020/05/17/relative-point...
A far pointer sounds like the global based pointer described in that article. The far pointer Wikipedia article says they are problematic but doesn't give much reasoning as to why.
Far pointers are for accessing memory in different segments. They're basically obsolete now. They were necessary in older machines with limited sized pointers or address spaces.
GCC still supports `__seg_fs` and `__seg_gs`, which behave similar to `far` in the example on the wiki page, as the FS and GS segment registers are still valid in x86-64 and used for TLS. Clang uses attributes `address_space(257)` and `address_space(256)` for the same thing.
The `__based` pointer in MSVC exploits the addressing modes by pinning the base in eg: `[base+index*scale+displacement]`. It's unrelated to segmentation.
> Far pointers are for accessing memory in different segments. They're basically obsolete now.
Project CHERI would like to disagree.
That's Fat pointers, not Far pointers. A fat pointer is a pointer with some other associated data which is stored in the pointer itself - typically by widening the number of bits used to hold a pointer value. The addressable bits usually remain unchanged - the added bits contain the auxiliary data.
Segmentation isn't used. There's no separate registers to hold the bounds information in CHERI - the bounds are held in the pointer value, unlike for example, the now obsolete Intel MPX, which held bounds information in separate registers.
There's some similarity to segmentation because the CHERI pointer restricts which addresses can be accessed, but I wouldn't compare them to far pointers.
Most modern processors have a single linear virtual address space and don't use segmentation, and even where segment registers exist (eg, FS and GS on x86-64), they're only superficial "address spaces" - allocated sections of the process's linear virtual address space which could be accessed without segmentation registers if you knew the base address held in FS or GS.
Not exactly what you asked, but c++ does this for vtables if you pass the right option to the compiler: -fexperimental-relative-c++-abi-vtables
There is a similar proposal for trait objects in rust.
in c++, boost interprocess has offset_ptr which is useful since the shared data structure may be mapped at different locations in memory in each process
Array indexing?