4 ms·

This is incorrect in two ways. First, Zig certainly has undefined behavior. Any non-memory-safe language trivially has UB. Second, this implicitly assumes that

This is incorrect in two ways. First, Zig certainly has undefined behavior. Any non-memory-safe language trivially has UB. Second, this implicitly assumes that terminating on OOM is not "correct" behavior, and handling OOM is the "correct" thing to do. But if there's nothing better that the app can do than to terminate on OOM, then terminating is the correct behavior. Many apps fall into this category. There's also the fact that OOM code paths tend not to be well-tested, so empirically aborting on OOM is a safer default.

skybrian 4y ago
There's a difference between a language allowing undefined behavior and a particular program written in that language exhibiting undefined behavior. The post you're replying to wasn't claiming that no Zig programs have undefined behavior, but rather that it should be be feasible to avoid it in the programs that you write. (I don't know if that will actually be true, though.)
- pcwalton 4y ago
  Well, that weaker sense of "correct programs have no UB" is true for Rust as well, then.
  - Schroedingersat 4y ago
    Rust has hidden allocation, no planned static stack analysis or limits on recursion, little to no control over how allocation happens, no ability to guarantee a panic won't happen and thus no ability for the programmer to guarantee eg. essential external resources are cleaned up. The guarantees that zig seeks to enable (this being the key phrase, it does not guarantee them just by its use, nor has the project solved all the problems this entails) the programmer to provide are non-goals of rust. Ie. the projects have completely different goals. The things zig want to provide would make rust unusable if it tried to provide them and vice versa.
    - zozbot234 4y ago
      Rust has had to implement limits on recursion already as part of async. It seems feasible to extend this to other code. And local allocators are also being worked on.
      - Schroedingersat 4y ago
        That's cool. Linky to discussions? I can't seem to search it.
Schroedingersat 4y ago
You've missed the point in at least two ways. The goal (not the present reality, although it's closer than most) is for the programmer to be able to get a particular program that is 100% defined behavior if they do everything right. Ie. it's a 'there exists' relationship. It's also an aspiration rather than an absolute (ie. make the tools progressively better for that purpose rather than making it an absolute constraint from day 0). Memory safe languages forbid certain classes of behavior preventing some bugs altogether. Ie. a 'for all' relationship. The correct behavior on OOM could also be defined as either checking whether allocation succeeded before moving on or as knowing how much memory you need and getting a guarantee it is available. You could be in a state where unpredicted termination has severe negative consequences (mission critical software, resources that need to be cleaned up). By pre-selecting a particular allocation strategy and response to failed allocation, and making it almost impossible to even know when allocation is attempted without reading every line of the massive stdlib you're making it impossible for the programmer to make that choice.

skybrian 4y ago

There's a difference between a language allowing undefined behavior and a particular program written in that language exhibiting undefined behavior. The post you're replying to wasn't claiming that no Zig programs have undefined behavior, but rather that it should be be feasible to avoid it in the programs that you write. (I don't know if that will actually be true, though.)

pcwalton 4y ago
Well, that weaker sense of "correct programs have no UB" is true for Rust as well, then.
- Schroedingersat 4y ago
  Rust has hidden allocation, no planned static stack analysis or limits on recursion, little to no control over how allocation happens, no ability to guarantee a panic won't happen and thus no ability for the programmer to guarantee eg. essential external resources are cleaned up. The guarantees that zig seeks to enable (this being the key phrase, it does not guarantee them just by its use, nor has the project solved all the problems this entails) the programmer to provide are non-goals of rust. Ie. the projects have completely different goals. The things zig want to provide would make rust unusable if it tried to provide them and vice versa.
  - zozbot234 4y ago
    Rust has had to implement limits on recursion already as part of async. It seems feasible to extend this to other code. And local allocators are also being worked on.
    - Schroedingersat 4y ago
      That's cool. Linky to discussions? I can't seem to search it.

Schroedingersat 4y ago

You've missed the point in at least two ways. The goal (not the present reality, although it's closer than most) is for the programmer to be able to get a particular program that is 100% defined behavior if they do everything right. Ie. it's a 'there exists' relationship. It's also an aspiration rather than an absolute (ie. make the tools progressively better for that purpose rather than making it an absolute constraint from day 0). Memory safe languages forbid certain classes of behavior preventing some bugs altogether. Ie. a 'for all' relationship. The correct behavior on OOM could also be defined as either checking whether allocation succeeded before moving on or as knowing how much memory you need and getting a guarantee it is available. You could be in a state where unpredicted termination has severe negative consequences (mission critical software, resources that need to be cleaned up). By pre-selecting a particular allocation strategy and response to failed allocation, and making it almost impossible to even know when allocation is attempted without reading every line of the massive stdlib you're making it impossible for the programmer to make that choice.