2 ms·

> You might be able to say something like "Zig minus features X, Y, and Z has full spatial memory safety". I'd be interested to see what features those are: it

> You might be able to say something like "Zig minus features X, Y, and Z has full spatial memory safety". I'd be interested to see what features those are: it looks like at a minimum you would have to get rid of multi-element pointers and extern unions. Well, `[*]` pointers and extern unions exist for C interoperability. I'm sure that Rust has to do something comparable when interfacing with C. These pointers actually do help making C interop more safe. In C there is no distinction at the type level between a pointer to a single element and a pointer to the first element of an array, so if you at some point get it wrong, the compiler can't help you. In Zig, if you annotate `extern` function signatures correctly, the compiler will be able to tell you when you're wrongly trying to iterate over a single-element pointer (or viceversa). That's a good feature to have, and IMO probably the worst supporting argument for your usual complaint about Zig's existence.

pcwalton 4y ago
I didn't say that multi-element pointers were a bad feature, simply that they're a counterexample to the claim that Zig has spatial memory safety. Generally in memory-safe languages the corresponding features are behind some kind of "unsafe" marker: in Rust and C# they're behind "unsafe", in Java they're behind "sun.misc.Unsafe", etc. I don't see any such marker in Zig.
- azakai 4y ago
  Is the marker the critical thing here, though? I just wrote in another comment that I think the Zig compiler can warn about using an unsafe pointer. The critical thing, I believe, is that unsafe can be discovered and audited. Unsafe pointers have a different type in Zig, so they are separable from the rest of the language, unless I'm missing something. The bottom line is that in a memory-safe language it should be possible to find all the unsafety and reason about it. For spatial memory safety that's not possible in C, but it is in Zig.
  - dcsommer 4y ago
    I would want to see an example of such a tool before comparing the two approaches or giving credit to Zig. As you admit in the other comment, even if such an "after the fact" tool can exist, still the net safety will be less. A compiler that does not force the developer to consciously think about safety at the time of using the unsafe feature increases the probability of misuse and safety defects.

pcwalton 4y ago

I didn't say that multi-element pointers were a bad feature, simply that they're a counterexample to the claim that Zig has spatial memory safety. Generally in memory-safe languages the corresponding features are behind some kind of "unsafe" marker: in Rust and C# they're behind "unsafe", in Java they're behind "sun.misc.Unsafe", etc. I don't see any such marker in Zig.

azakai 4y ago
Is the marker the critical thing here, though? I just wrote in another comment that I think the Zig compiler can warn about using an unsafe pointer. The critical thing, I believe, is that unsafe can be discovered and audited. Unsafe pointers have a different type in Zig, so they are separable from the rest of the language, unless I'm missing something. The bottom line is that in a memory-safe language it should be possible to find all the unsafety and reason about it. For spatial memory safety that's not possible in C, but it is in Zig.
- dcsommer 4y ago
  I would want to see an example of such a tool before comparing the two approaches or giving credit to Zig. As you admit in the other comment, even if such an "after the fact" tool can exist, still the net safety will be less. A compiler that does not force the developer to consciously think about safety at the time of using the unsafe feature increases the probability of misuse and safety defects.