4 ms·

Zig isn't a memory safe language, but it does have memory safety features. Theoretically it's safer than C but isn't as safe as Rust. For example, you can't ov

Zig isn't a memory safe language, but it does have memory safety features. Theoretically it's safer than C but isn't as safe as Rust. For example, you can't overflow buffers (slices have associated lengths that are automatically checked at runtime), pointers can't be null, integer overflows panic.

renox 2y ago
> integer overflows panic Not in all the ReleaseFast mode where both signed and unsigned overflow have undefined behaviour. And there's also the aliasing issue, if you have fn f(a:A, b: b:*A) { b = <>; which value has 'a' when f is called with f(a,a)? } (not sure about Zig's syntax). That said I agree with your classification (safer than C but isn't as safe as Rust)
- tialaramex 2y ago
  Zig doesn't provide any rationale for why it picked UB rather than wrapping. By default Rust's release builds give the integer overflows wrapping, so (1u8 + 255u8 == 0u8) rather than panic, so as to avoid paying for the checks. This is probably not what you wanted, your code has a bug (if it was what you wanted, you should use the Wrapping type wrapper which says what you meant, not just insist this code must be compiled with specific settings) but you didn't have to pay for checks and your program continues to have defined behaviour, like any normal bug. It is very rare that you need the unchecked behaviour for performance. Rare enough that although Wrapping and Saturating wrappers exist in Rust, even the basic operations for unchecked arithmetic are still nightly only. Most often what people meant is a checked arithmetic operation in which they need to write code to handle the case where there would be overflow, not an unchecked operation, Rust even has caution notes to guide newbies who might write a manual check - pushing them towards the pit of success - hey, instead of your manual check and then unsafe arithmetic, why not use this nice checked function which, in fact, compiles to the same machine code.
  - renox 2y ago
    > Zig doesn't provide any rationale for why it picked UB rather than wrapping There's no need to provide a rationale because it's obvious, from a performance POV: 1) (a) UB on overflow > (b)wrapping on overflow 2) (b)wrapping on overflow > (c)trap on overflow. So when you create a language you have to pick a default behaviour, Zig allow both (a) xor (c) with ReleaseFast and ReleaseSafe.. (1) is because this allows the compiler to do "better" optimisations, which unfortunately can create lots of pain for you if your code has a bug. (2) is because these f.. CPU designers don't provide an 'add_trap_on_overflow' instruction so at the very least the overflow check instruction degrades the instruction cache utilisation.
    - davemp 2y ago
      It’s worth pointing out that Zig also just straight up gives you wrapping and saturating adds with ‘+%’ and ‘+|’ operations and same for other arithmetic operations.
    - tialaramex 2y ago
      > 1) (a) UB on overflow > (b)wrapping on overflow Alas no, you've written a greater than sign but you'll find in reality it's often only the same. But you've significantly weakened the language, so you just made the language worse and you need to identify what you got for this price. On the one hand, since you didn't promise wrapping in some cases you'll astonish your programmers when you don't provide it but that's what they expected, on the other since can't always get better performance you'll sometimes disappoint them by not going any faster despite not promising wrapping. This might all be worth it if in the usual case you were much faster, but, in practice that's not what we see.
      - int_19h 2y ago
        One can reasonably argue that the only reason why people expect wraparound is because it was the default in C, not because it actually makes sense. If the code actually depends on wraparound to produce the correct result, making that explicit in the operators, as Zig does, is surely a better choice, not the least because it gives people reading the code a clear indication that they should be paying attention to that. OTOH most code out there in the wild treats it more as a "never gonna happen" situation and doesn't deal with it at all, which isn't really made any worse with full-fledged UB.
- codethief 2y ago
  > And there's also the aliasing issue Plans to address this were shared just last week: https://github.com/ziglang/zig/issues/5973#issuecomment-2380332493 https://github.com/ziglang/zig/issues/5973#issuecomment-2380...
  - renox 2y ago
    Thanks for the information. I'm relieved that they decided to remove this trap as it could really have been a nasty one (worse than integer overflow because you can just use ReleaseSafe)

renox 2y ago

> integer overflows panic Not in all the ReleaseFast mode where both signed and unsigned overflow have undefined behaviour. And there's also the aliasing issue, if you have fn f(a:A, b: b:*A) { b = <>; which value has 'a' when f is called with f(a,a)? } (not sure about Zig's syntax). That said I agree with your classification (safer than C but isn't as safe as Rust)

tialaramex 2y ago
Zig doesn't provide any rationale for why it picked UB rather than wrapping. By default Rust's release builds give the integer overflows wrapping, so (1u8 + 255u8 == 0u8) rather than panic, so as to avoid paying for the checks. This is probably not what you wanted, your code has a bug (if it was what you wanted, you should use the Wrapping type wrapper which says what you meant, not just insist this code must be compiled with specific settings) but you didn't have to pay for checks and your program continues to have defined behaviour, like any normal bug. It is very rare that you need the unchecked behaviour for performance. Rare enough that although Wrapping and Saturating wrappers exist in Rust, even the basic operations for unchecked arithmetic are still nightly only. Most often what people meant is a checked arithmetic operation in which they need to write code to handle the case where there would be overflow, not an unchecked operation, Rust even has caution notes to guide newbies who might write a manual check - pushing them towards the pit of success - hey, instead of your manual check and then unsafe arithmetic, why not use this nice checked function which, in fact, compiles to the same machine code.
- renox 2y ago
  > Zig doesn't provide any rationale for why it picked UB rather than wrapping There's no need to provide a rationale because it's obvious, from a performance POV: 1) (a) UB on overflow > (b)wrapping on overflow 2) (b)wrapping on overflow > (c)trap on overflow. So when you create a language you have to pick a default behaviour, Zig allow both (a) xor (c) with ReleaseFast and ReleaseSafe.. (1) is because this allows the compiler to do "better" optimisations, which unfortunately can create lots of pain for you if your code has a bug. (2) is because these f.. CPU designers don't provide an 'add_trap_on_overflow' instruction so at the very least the overflow check instruction degrades the instruction cache utilisation.
  - davemp 2y ago
    It’s worth pointing out that Zig also just straight up gives you wrapping and saturating adds with ‘+%’ and ‘+|’ operations and same for other arithmetic operations.
  - tialaramex 2y ago
    > 1) (a) UB on overflow > (b)wrapping on overflow Alas no, you've written a greater than sign but you'll find in reality it's often only the same. But you've significantly weakened the language, so you just made the language worse and you need to identify what you got for this price. On the one hand, since you didn't promise wrapping in some cases you'll astonish your programmers when you don't provide it but that's what they expected, on the other since can't always get better performance you'll sometimes disappoint them by not going any faster despite not promising wrapping. This might all be worth it if in the usual case you were much faster, but, in practice that's not what we see.
    - int_19h 2y ago
      One can reasonably argue that the only reason why people expect wraparound is because it was the default in C, not because it actually makes sense. If the code actually depends on wraparound to produce the correct result, making that explicit in the operators, as Zig does, is surely a better choice, not the least because it gives people reading the code a clear indication that they should be paying attention to that. OTOH most code out there in the wild treats it more as a "never gonna happen" situation and doesn't deal with it at all, which isn't really made any worse with full-fledged UB.
codethief 2y ago
> And there's also the aliasing issue Plans to address this were shared just last week: https://github.com/ziglang/zig/issues/5973#issuecomment-2380332493 https://github.com/ziglang/zig/issues/5973#issuecomment-2380...
- renox 2y ago
  Thanks for the information. I'm relieved that they decided to remove this trap as it could really have been a nasty one (worse than integer overflow because you can just use ReleaseSafe)