3 ms·

The recommended way to deal with use-after-free and double-free in the language is to do it in test. You can pretty trivially get "asan"-like behaviours out of

The recommended way to deal with use-after-free and double-free in the language is to do it in test. You can pretty trivially get "asan"-like behaviours out of the zig std library. A good demonstration is here: https://www.youtube.com/watch?v=4nVhByP-npU&t=3h12m https://www.youtube.com/watch?v=4nVhByP-npU&t=3h12m I kind of like this philosophy, because in a sly way it's a carrot to get you to write tests. Come for the memory safety, stay for the robustness. As a bonus, the beginning 2 hours of the video is a fantastic and honest discussion about the role of emotional empathy in tech communities and tech employment (while also acknowledging that it is possible to be an asshole and deliver good tech).

jamii 6y ago
That's also the recommended way to deal with it in c. It hasn't been effective in preventing vulnerabilities based on use-after-free. If the GPA is practical to use in production, that will be a different story. But it doesn't sound like it's there yet.
- dnautics 6y ago
  True, UAF still kind of sucks in zig. My prediction is that we are going to eventually get some sort of formal verification engine for zig as a third party tool.
pjmlp 6y ago
Unless the test proves all use cases in production, it is no better than C with ASAN.
AndyKelley 6y ago
To be clear - you get this same UAF protection in ReleaseSafe mode by default with GeneralPurposeAllocator and PageAllocator. It's not just a test thing. The testing system just chooses some nice defaults for you.
- dnautics 6y ago
  thanks for the clarification! Also, you can arbitrarily compose GPA backended by other allocators that aren't pageallocator, in which case you might lose the early-exit segfault behavior.
mlindner 6y ago
This is as ridiculous as it is in C. You can't be sure you're testing all the user after free cases and if the code changes and you forget to update the test then you have no idea that you could have added a use after free. Tests rot over time. The more I read about Zig I feel like it's made for C programmers stuck in the Stockholm Syndrome of C and don't want out. (Speaking as a former C programmer.)

jamii 6y ago

That's also the recommended way to deal with it in c. It hasn't been effective in preventing vulnerabilities based on use-after-free. If the GPA is practical to use in production, that will be a different story. But it doesn't sound like it's there yet.

dnautics 6y ago
True, UAF still kind of sucks in zig. My prediction is that we are going to eventually get some sort of formal verification engine for zig as a third party tool.

pjmlp 6y ago

Unless the test proves all use cases in production, it is no better than C with ASAN.

AndyKelley 6y ago

To be clear - you get this same UAF protection in ReleaseSafe mode by default with GeneralPurposeAllocator and PageAllocator. It's not just a test thing. The testing system just chooses some nice defaults for you.

dnautics 6y ago
thanks for the clarification! Also, you can arbitrarily compose GPA backended by other allocators that aren't pageallocator, in which case you might lose the early-exit segfault behavior.

mlindner 6y ago

This is as ridiculous as it is in C. You can't be sure you're testing all the user after free cases and if the code changes and you forget to update the test then you have no idea that you could have added a use after free. Tests rot over time. The more I read about Zig I feel like it's made for C programmers stuck in the Stockholm Syndrome of C and don't want out. (Speaking as a former C programmer.)