News for hackers. Stuff that matters.
Re:This shouldn't have happened: A vulnerability postmortem by IggleSniggle on Wednesday December 01, 2021 @06:27PM (#29410463)
One of the things I like about Zig is that it takes the memory allocator as a kind of “you will supply the correct model for this for your needs/architecture” as a first principle, and then gives you tooling to provide guarantees downstream. You’re not stuck with any assumptions about malloc like you might be with C libs.

On the one hand, you might need to care more about what allocators you use for a given use case. On the other hand, you can make the allocator “conform” to a set of constrictions, and as long as it conforms at `comptime`, you can make guarantees downstream to any libraries, with the a sort of fundamental “dependency injection” effect that flows through your code at compile time.

Re:This shouldn't have happened: A vulnerability postmortem by pcwalton on Wednesday December 01, 2021 @09:31PM (#29411825)
Zig is, however, not memory safe, which outweighs all of those benefits in this context.
Re:This shouldn't have happened: A vulnerability postmortem by IggleSniggle on Thursday December 02, 2021 @02:31PM (#29421241)
It can be memory safe. It's up to you to choose memory safety or not. That's a piece of what I was getting at. Unless I misunderstand something. I've only dabbled with Zig.
Re:This shouldn't have happened: A vulnerability postmortem by pcwalton on Friday December 03, 2021 @03:29PM (#29434943)
I'm not aware of any memory safety that works in Zig, other than maybe Boehm GC. The GeneralPurposeAllocator quarantines memory forever, which is too wasteful to work in practice as one allocation is sufficient to keep an entire 4kB page alive.