Tip of the day #2: A safer arena allocator
The most transformative action you can do to dramatically improve your code in a programming language where you are in control of the memory is: to use arenas.
Much has been written about arenas (1, 2). In short, it means grouping multiple allocations with the same lifetime in one batch that gets allocated and deallocated only once.
Another way to look at it, is that the allocations are append only. They never get freed during their 'life'. The program is split into 'phases'. Typically, each phase has its own arena, and when it reaches its end, the whole arena gets nuked from space along with all entities allocated from it. It's a great way to simplify the code, make it faster, and escape from the 'web of pointers' hell.
Very simple, just ask the OS to give us a region of virtual memory and off we go (on Windows, the system call is named differently but is equivalent).
Now, since we use a system call directly, sanitizers and runtime checks from the libc allocator do not apply, since we bypass them completely. In a way, it is also a feature: it means that our program will behave exactly the same on all OSes, have the exact same memory layout, and use the exact same amount of memory. It does not depend on the libc or allocator.
