Hacker News new | ask | show | jobs
by tptacek 5142 days ago
I'll make a stand for it being bad style to free() memory when in any reasonable run of the program exit() would free just as effectively. This is simply arena allocation; some very excellent, well-regarded C code uses arenas and pools in the same idiom.

The downside to calling free(), apart from performance (malloc/free are extremely expensive), is that messing them up creates bugs that are much worse than simply holding on to some allocator metadata until the program hits exit().
2 comments
leif 5142 days ago
The upside to calling free() is that it is a valuable lesson in understanding memory lifetimes for a beginner programmer. You can't know when it's good to omit free until you know what it means.
link
derleth 5142 days ago
> messing them up creates bugs

Messing them up exposes bugs that are likely to bite you in other ways. If you can't get malloc()/free() right, you don't really 'get' the flow control/data flow through your program yet and that is a problem.

link
tptacek 5142 days ago
Arena allocation is inherently simpler and less error-prone than demand-allocating and demand-freeing. It's not valid to say that arena allocation is "hiding" bugs; what it's doing is foreclosing on the possibility of having those bugs.

Virtually no large project has ever gotten malloc/free completely right in its first revision; for the past 20 years or so, most projects get this wrong to the tune of "remote code execution".

link