4 ms·

That's humorous but sad in so many ways. Regarding the original quote - if I see a malloc for a bunch of memory intended for the lifetime of the app and it's at

That's humorous but sad in so many ways. Regarding the original quote - if I see a malloc for a bunch of memory intended for the lifetime of the app and it's at the beginning of main and then it doesn't get freed before the end of process execution it's not really a memory leak in my book. Still, I wouldn't write code like that.

zlynx 9y ago
A variant of that I've seen in many small 1990s C apps is create a huge struct with all the program data in it, with fixed size arrays of things big enough so that's all you ever need, and just declare one global struct. It was one struct instead of separate globals because of some coding style guide at the time. "But what if we want to use this in a library?" "Here's all the data in one container, malloc it and use that." I don't think many of those programs ever did end up in libraries.
- MBCook 9y ago
  So basically the way people ‘allocated’ memory in small assembly programs.
- tempodox 9y ago
  The original yacc(1) was written with fixed-size arrays for the parser tables, statically allocated. If the parser was too complex, the arrays would blow. To fix that, change the DEFINEs and recompile yacc.
wahern 9y ago
> if I see a malloc for a bunch of memory intended for the > lifetime of the app and it's at the beginning of main and > then it doesn't get freed before the end of process > execution it's not really a memory leak in my book. Not freeing such memory and otherwise not explicitly destroying all your state can hide bugs, hide legitimate leaks, and add noise to memory profilers like valgrind. Destroying your state exercises those code pathways, which is very valuable. Plus, it's just a good habit in a language with manual memory management. It's like wearing your seatbelt--if it's a habit you just do it as a matter of course without thought, no matter whether you're driving around the block or across the country. You start making exceptions, you break the habit, you invite errors of judgment.
- zwieback 9y ago
  Yes, the reasons you mention are why I would always free pre-malloced memory. However, a real memory leak, to me, is memory that gets allocated at different times through the lifetime of the app and doesn't get reliably freed do to unexpected code paths or race conditions. If I don't see the allocation count rise steadily while I run my app I'm not as worried.

zlynx 9y ago

A variant of that I've seen in many small 1990s C apps is create a huge struct with all the program data in it, with fixed size arrays of things big enough so that's all you ever need, and just declare one global struct. It was one struct instead of separate globals because of some coding style guide at the time. "But what if we want to use this in a library?" "Here's all the data in one container, malloc it and use that." I don't think many of those programs ever did end up in libraries.

MBCook 9y ago
So basically the way people ‘allocated’ memory in small assembly programs.
tempodox 9y ago
The original yacc(1) was written with fixed-size arrays for the parser tables, statically allocated. If the parser was too complex, the arrays would blow. To fix that, change the DEFINEs and recompile yacc.

wahern 9y ago

> if I see a malloc for a bunch of memory intended for the > lifetime of the app and it's at the beginning of main and > then it doesn't get freed before the end of process > execution it's not really a memory leak in my book. Not freeing such memory and otherwise not explicitly destroying all your state can hide bugs, hide legitimate leaks, and add noise to memory profilers like valgrind. Destroying your state exercises those code pathways, which is very valuable. Plus, it's just a good habit in a language with manual memory management. It's like wearing your seatbelt--if it's a habit you just do it as a matter of course without thought, no matter whether you're driving around the block or across the country. You start making exceptions, you break the habit, you invite errors of judgment.

zwieback 9y ago
Yes, the reasons you mention are why I would always free pre-malloced memory. However, a real memory leak, to me, is memory that gets allocated at different times through the lifetime of the app and doesn't get reliably freed do to unexpected code paths or race conditions. If I don't see the allocation count rise steadily while I run my app I'm not as worried.