Re:How safe is Zig?
by 10000truths on Thursday June 23, 2022 @01:12PM
(#31852168)
Alternatively, use offset values instead of internal pointers. Now your structs are trivially relocatable, and you can use smaller integer types instead of pointers, which allows you to more easily catch overflow errors.
Re:How safe is Zig?
by anonymoushn on Thursday June 23, 2022 @01:20PM
(#31852282)
This is a good idea, but native support for slices tempts one to stray from the path.
> so they would be avoided if we had non-movable/non-copyable types.
There is a proposal for this that was accepted a while ago[0]. However, the devs have been focused on the self-hosted compiler recently, so they're behind on actually implementing accepted proposals.
Re:How safe is Zig?
by throwawaymaths on Thursday June 23, 2022 @01:03PM
(#31852008)
This. I believe it is in the works, but postponed to finish up self-hosted.
Many of the dangling stack pointers I've caught in code review don't really look like the above. Instead, they're dangling pointers that are intended to be internal pointers, so they would be avoided if we had non-movable/non-copyable types. I'm not sure such types are worth the trouble otherwise though. Personally, I've just stopped making structs that use internal pointers. In a typical case, instead of having an internal array and a slice into the array, a struct can have an internal heap-allocated slice and another slice into that slice. like I said, I'd like these thorns to be less thorny somehow.