4 ms·
Probably just a small miss, but in the first section the author refers to stack space limitations possibly hit when calling malloc. That should probably refer t
by olodus 4y ago
Probably just a small miss, but in the first section the author refers to stack space limitations possibly hit when calling malloc. That should probably refer to heap space. Or if it is stack space they meant then maybe not malloc but rather stack allocations / function calls.
- olodus 4y agoBesides that little inaccuracy I very much agree with most things in the article and think it brings up good points. Specifically the part about allocator handling is a huge thing for me. Having the allocator be a global thing has always been a bit of a cheat imo and it solves so many memory issues just to remove that part. And opens up some optimization possibilities ad well. I do agree with some of zigs Cons that you bring up as well. Currently I have really been into Linear types and feel like that would be the perfect "simple" type-based memory safety zig could incorporate without making it too c++ complicated. But at the same time I don't know if it would work with its comptime and maybe it too would compromise on the simpleness of the language. I don't know.
- jamincan 4y agoI think he's referring to the fact that as a function, calls to malloc result in a new stack frame.
- messe 4y agoI think they’re actually referring the stack usage from the function call itself (the creation of a new stack frame). I believe the point the author is making is that while it’s common to check the return value of malloc to see if heap allocation was successful, it’s comparatively rare to do any analysis of stack usage to verify that none of your function calls are going to cause a stack overflow.
- monocasa 4y agoRust at least will stack probe to trigger any guard pages upon allocation.