18 ms·

Not GP. > I'm very skeptical that the lack of memory safety is not going to be an issue "in practice". For what it's worth, I agree with you. And I'm a C prog

Not GP. > I'm very skeptical that the lack of memory safety is not going to be an issue "in practice". For what it's worth, I agree with you. And I'm a C programmer that managed to put out a non-trivial piece of C code ([1]) that has had no memory safety issues triggered in the wild after 1.0 (which was released on 26 Oct 2018, so almost 4 years, yay!) that I know of. The truth is that I am not able to write such code; I just fuzz the ever-living daylights out of my code with lots of asserts to test all of the assumptions that my code makes, including preconditions, postconditions, everything. I also use static analysis, -Weverything on Clang (without -Wpadded; that's a stupid warning), and a massive test suite with near 100% coverage. In my new projects, I'm even using fuzzing to generate almost all of my test cases so that my path coverage is as good as possible. That's a lot of work, and it's not fun. But what would make it even more effective would be to effectively automatically add asserts for me to test the assumption that an index is in range whenever it is used! And that's why memory-safe languages are the only way to go: not only do they save people from bad code, they help programmers turn bad code into good code with the tools at their disposal. I think the Zig people know this, which is why they have ReleaseSafe for testing and for those cases where you have to be sure. But I also don't see them test their code enough for me to trust that it's not needed. And I doubt that Zig users test their code enough for it too. All of this is to say, I completely agree with you despite (so far!) being the exception to the rule you articulated, and I dread the day when my reign of "being the exception" comes to an end. I really want to stay being the exception. [1]: https://git.yzena.com/gavin/bc https://git.yzena.com/gavin/bc

pjmlp 4y ago
Congratulations for being part of the minority that cares, On my experience, only small teams with top devs do happen to care for doing the security work you describe, as tends to be proven by surveys regarding the use of unit testing or static analysis tooling, https://www.jetbrains.com/lp/devecosystem-2021/c/ https://www.jetbrains.com/lp/devecosystem-2021/c/ https://www.jetbrains.com/lp/devecosystem-2021/cpp/ https://www.jetbrains.com/lp/devecosystem-2021/cpp/ So yeah, pity that memory-safe languages have to fight back to regain what was already possible before UNIX took over the computing world and brought C for the ride. This is why I would like that Zig could offer more than Modula-2 already did in 1978, in regards to memory corruption.
- ghoward 4y ago
  Yeah, I agree, and I like C! I think the lack of bounds checks where they are not a problem is a massive design flaw nowadays. Zig should have made bounds checks universal and spent effort on compiler passes to elide them. Allowing people to remove bounds checks is not smart (though Rust's unsafe is a good compromise), especially in such a coarse way as a build option. In fact, a supposedly memory-safe language, Julia, has memory bugs because it allows users to turn bounds checks off. [1] This should never have happened. [1]: https://yuri.is/not-julia/ https://yuri.is/not-julia/
Schroedingersat 4y ago
The goal of the Zig project isn't to get rid of that work. It's to make it easier. ReleaseSafe is supposed to be the 'normal' way to compile (the same role O2 takes now albeit with a performance penalty compared to O2), with releasefast or releasesmall for those times performance is unacceptable and where you've satisfied yourself with the level of testing you've done. The philosophy of the project is to build some of those static analyses and runtime checks that help fuzzing into the compiler and stdlib. And build a culture and toolchain where it's easy to start using the rest as part of the status quo (rather than them being the exotic thing used by weird people). Finally they get rid of some of the most egregious footguns ( ostly relevant to beginners), passing slices is much more ergonomic and less error prone for a beginner, the error handling is best in class, and there are optional types and less use of void pointers. Of course doing the actual hard work is always going to be hard work. But you can turn it from hard and gruelling work where the majority of people have no idea of the things they should even be doing and where you uave to keep a laundry list of gotchyas in your head into hard but satisfying work that feels fathomable. It's a different philosophy from rust, but one that is no less valid.
- gavinhoward 4y ago
  The error handling is so far from best-in-class that it's not even funny. Lisp conditions and restarts, which can be implemented in C, are best-in-class. Beyond that, does Zig allow arbitrary values as errors now? Anything that doesn't is not best-in-class; they would be worst-in-class. Footguns are never just relevant to beginners. I say this as something close to an expert C programmer. I hit footguns all of the time. I just don't release them because I always assume I hit them and hunt them down. Making things easier to fuzz is table stakes; even C can do that now. I set up fuzzing for my code with a simple build option. It's not hard. It's also effective at finding test cases for you, if you use it right. Does Zig do Design by Contract? That would make fuzzing easier. Does it do Property-Based Testing? That's a more focused version of fuzzing. In fact, it's the same to unit testing as fuzzing is to integration testing. Until Zig has Property-Based Testing, I don't believe it's making testing easier. For that matter, as far as I know, Zig only makes unit tests easy. Unit tests are okay, but not really effective. The test suite for my code is only integration tests, which makes things easier to refactor. And yet it is effective at finding bugs. tl;dr: What Zig has is table stakes in 2022. It is nothing special for helping people write correct code.

pjmlp 4y ago

Congratulations for being part of the minority that cares, On my experience, only small teams with top devs do happen to care for doing the security work you describe, as tends to be proven by surveys regarding the use of unit testing or static analysis tooling, https://www.jetbrains.com/lp/devecosystem-2021/c/ https://www.jetbrains.com/lp/devecosystem-2021/c/ https://www.jetbrains.com/lp/devecosystem-2021/cpp/ https://www.jetbrains.com/lp/devecosystem-2021/cpp/ So yeah, pity that memory-safe languages have to fight back to regain what was already possible before UNIX took over the computing world and brought C for the ride. This is why I would like that Zig could offer more than Modula-2 already did in 1978, in regards to memory corruption.

ghoward 4y ago
Yeah, I agree, and I like C! I think the lack of bounds checks where they are not a problem is a massive design flaw nowadays. Zig should have made bounds checks universal and spent effort on compiler passes to elide them. Allowing people to remove bounds checks is not smart (though Rust's unsafe is a good compromise), especially in such a coarse way as a build option. In fact, a supposedly memory-safe language, Julia, has memory bugs because it allows users to turn bounds checks off. [1] This should never have happened. [1]: https://yuri.is/not-julia/ https://yuri.is/not-julia/

Schroedingersat 4y ago

The goal of the Zig project isn't to get rid of that work. It's to make it easier. ReleaseSafe is supposed to be the 'normal' way to compile (the same role O2 takes now albeit with a performance penalty compared to O2), with releasefast or releasesmall for those times performance is unacceptable and where you've satisfied yourself with the level of testing you've done. The philosophy of the project is to build some of those static analyses and runtime checks that help fuzzing into the compiler and stdlib. And build a culture and toolchain where it's easy to start using the rest as part of the status quo (rather than them being the exotic thing used by weird people). Finally they get rid of some of the most egregious footguns ( ostly relevant to beginners), passing slices is much more ergonomic and less error prone for a beginner, the error handling is best in class, and there are optional types and less use of void pointers. Of course doing the actual hard work is always going to be hard work. But you can turn it from hard and gruelling work where the majority of people have no idea of the things they should even be doing and where you uave to keep a laundry list of gotchyas in your head into hard but satisfying work that feels fathomable. It's a different philosophy from rust, but one that is no less valid.

gavinhoward 4y ago
The error handling is so far from best-in-class that it's not even funny. Lisp conditions and restarts, which can be implemented in C, are best-in-class. Beyond that, does Zig allow arbitrary values as errors now? Anything that doesn't is not best-in-class; they would be worst-in-class. Footguns are never just relevant to beginners. I say this as something close to an expert C programmer. I hit footguns all of the time. I just don't release them because I always assume I hit them and hunt them down. Making things easier to fuzz is table stakes; even C can do that now. I set up fuzzing for my code with a simple build option. It's not hard. It's also effective at finding test cases for you, if you use it right. Does Zig do Design by Contract? That would make fuzzing easier. Does it do Property-Based Testing? That's a more focused version of fuzzing. In fact, it's the same to unit testing as fuzzing is to integration testing. Until Zig has Property-Based Testing, I don't believe it's making testing easier. For that matter, as far as I know, Zig only makes unit tests easy. Unit tests are okay, but not really effective. The test suite for my code is only integration tests, which makes things easier to refactor. And yet it is effective at finding bugs. tl;dr: What Zig has is table stakes in 2022. It is nothing special for helping people write correct code.