Zig: Pointer Stability for ArrayLists • Hacker News Board

Re: Zig: Pointer Stability for ArrayLists

#21

Post by duped » Sun, Aug 30, 2026, 8:06 PM UTC

pron wrote: post #16

amluto wrote: post #7

This seems weak. In a language like Rust, the compiler will “lock” the pointers for you, and you can’t forget. In a language like C++ (and presumably Zig), one could, in theory at least, have the iterators and slices that reference the storage of a dynamic array hold some sort of lock that pins the storage. But this API requires the programmer to remember to lock the pointers and also requires the programmer to keep…

I reach for a low-level language only when I want low-level control over what operations happen and when, what memory is used and when etc.. At present, no language offers me this control and safety at the same time. With Rust, when I need such control (which is always, otherwise I would use a higher-level language), I need to give up safety, anyway, at which point I have no safety and the complexity of a language th…

What are some examples of things you "always" need that require unsafe Rust?

Re: Zig: Pointer Stability for ArrayLists

#22

Post by duped » Sun, Aug 30, 2026, 8:10 PM UTC

This is a gripe of mine, and I will admit it is weak.

Changing a segfault to a panic with a stack trace is an improvement in developer experience. It does not make better software. The advantage of automatic strategies to mitigate memory safety mistakes either by using GC to make the program sound or static analysis to prevent the mistake by construction is plainly better.

There is a direction in some systems programming circles away from this by eschewing "complexity" (in other words, fixing the damn problems) for programs that have better error messages when the programmer made a mistake. I don't see that as better software.

Re: Zig: Pointer Stability for ArrayLists

#23

Post by Someone » Sun, Aug 30, 2026, 8:19 PM UTC

frmdstryr wrote: post #19

amluto wrote: post #7

This seems weak. In a language like Rust, the compiler will “lock” the pointers for you, and you can’t forget. In a language like C++ (and presumably Zig), one could, in theory at least, have the iterators and slices that reference the storage of a dynamic array hold some sort of lock that pins the storage. But this API requires the programmer to remember to lock the pointers and also requires the programmer to keep…

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.

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.

Re: Zig: Pointer Stability for ArrayLists

#24

Post by boricj » Sun, Aug 30, 2026, 8:21 PM UTC

It took me a minute to understand that this asserts on pointer change within the container, rather than lock/unlock the data structure like a SDL surface.

I recently implemented a custom C++ container for a path whose components could be iterated, backed by a std::string. I just store indices and a reference to the string, such that my iterators are not invalidated if the std::string gets reallocated after being modified. Far less error prone for little added cost.

Re: Zig: Pointer Stability for ArrayLists

#25

Post by portly » Sun, Aug 30, 2026, 8:50 PM UTC

This makes a lot of sense if you consider that it is consistent with the rest of the language. It is one more way to set up tripwires in your code to to catch your own programming errors. Similar to using asserts in your functions to vet input and output.

I use Array list a lot so excited to add this throughout the code to harden them.

I can imagine this is not everyone's cup of tea, but then you probably also wouldn't enjoy any of the other explicitness.

Re: Zig: Pointer Stability for ArrayLists

#26

Post by xeonmc » Sun, Aug 30, 2026, 9:05 PM UTC

pron wrote: post #16

amluto wrote: post #7

This seems weak. In a language like Rust, the compiler will “lock” the pointers for you, and you can’t forget. In a language like C++ (and presumably Zig), one could, in theory at least, have the iterators and slices that reference the storage of a dynamic array hold some sort of lock that pins the storage. But this API requires the programmer to remember to lock the pointers and also requires the programmer to keep…

I reach for a low-level language only when I want low-level control over what operations happen and when, what memory is used and when etc.. At present, no language offers me this control and safety at the same time. With Rust, when I need such control (which is always, otherwise I would use a higher-level language), I need to give up safety, anyway, at which point I have no safety and the complexity of a language th…

    Those who would give up low-level control to purchase a little memory safety, deserve neither control nor safety.”

- Benjamin Franklin, or something like that

Re: Zig: Pointer Stability for ArrayLists

#27

Post by sparkie » Sun, Aug 30, 2026, 9:11 PM UTC

Someone wrote: post #23

frmdstryr wrote: post #19

Earlier quoted context omitted.

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.

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.

Re: Zig: Pointer Stability for ArrayLists

#28

Post by amluto » Sun, Aug 30, 2026, 9:17 PM UTC

frmdstryr wrote: post #19

amluto wrote: post #7

This seems weak. In a language like Rust, the compiler will “lock” the pointers for you, and you can’t forget. In a language like C++ (and presumably Zig), one could, in theory at least, have the iterators and slices that reference the storage of a dynamic array hold some sort of lock that pins the storage. But this API requires the programmer to remember to lock the pointers and also requires the programmer to keep…

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.

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.

Re: Zig: Pointer Stability for ArrayLists

#29

Post by frmdstryr » Sun, Aug 30, 2026, 9:23 PM UTC

Someone wrote: post #23

frmdstryr wrote: post #19

Earlier quoted context omitted.

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.

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.

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.

Re: Zig: Pointer Stability for ArrayLists

#30

Post by sparkie » Sun, Aug 30, 2026, 9:56 PM UTC

frmdstryr wrote: post #29

Someone wrote: post #23

Earlier quoted context omitted.

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.

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.