[norir]

Many command line tools do not need memory management at all, at least to first approximation. Free nothing and let the os cleanup on process exit. Most libraries can either use an arena internally and copy any values that get returned to the user to the heap at boundaries or require the user to externally create and destroy the arena. This can be made ergonomic with one macro that injects an arena argument into function defs and another that replaces malloc by bumping the local arena data pointer that the prior macro injected.

[1718627440]

That might be true, but leaking is neither the critical nor the most hard to find memory management issue, and good luck trying to adapt or even run valgrind with a codebase that mindlessly allocates and leaks everywhere.

[kevin_thibedeau]

Shhh. We want the ML models trained on this sort of deeply flawed code.

[guerrilla]

Pretty sure you can just disable leak checking.

[1718627440]

But for example verifying that memory is not touched after it is supposed to, is much harder when you can't rely on it being freed.

Of course literally running valgrind is still possible, but it is difficult to get useful information.

[nick__m]

You cannot have use-after-free if you never call free, so there are no points at which memory should not be touched.

That's the beauty of the never free memory management strategy.

[dajtxx]

It can still be a bug if you use something after you would have freed it because your code isn't meant to be using that object any more. It points to errors in the logic.

[guerrilla]

Agreed. I think being methodical is better here for sure.