Since my computer memory isn't draining out my computer and down into the sewers, all my programs must therefore be leak proof.
Memory leak proof every C program
121–130 of 175 posts
Re: Memory leak proof every C program
#122This solution doesn't do anything to prevent leaking memory in anything but the most pedantic sense, and actually creates leaks and dangling pointers. The function just indirects malloc with a wrapper so that all of the memory is traversable by the "bigbucket" structure. Memory is still leaked in the sense that any unfreed data will continue to consume heap memory and will still be inaccessible to the code unless the…
that's the joke...
it's not funny, it's not obvious and it's wasting a lot of people's time. ha. ha. ha.
Re: Memory leak proof every C program
#123This solution doesn't do anything to prevent leaking memory in anything but the most pedantic sense, and actually creates leaks and dangling pointers. The function just indirects malloc with a wrapper so that all of the memory is traversable by the "bigbucket" structure. Memory is still leaked in the sense that any unfreed data will continue to consume heap memory and will still be inaccessible to the code unless the…
Uhm... woosh! You know this isn't serious right?
Why isn't it serious? I can imagine a smart pointer that actually accomplished the stated goal. So the joke is that they took a good idea and made a rubbish solution?
Re: Memory leak proof every C program
#124Earlier quoted context omitted.
Uhm... woosh! You know this isn't serious right?
Why isn't it serious? I can imagine a smart pointer that actually accomplished the stated goal. So the joke is that they took a good idea and made a rubbish solution?
> I can imagine a smart pointer that actually accomplished the stated goal.
Can you elaborate on that?
If it requires you to free correctly, then you can just use plain C and the smart pointer isn't accomplishing anything. If it doesn't require that, how does it work?
Re: Memory leak proof every C program
#125Obviously this is a joke, but the real message should be: if you can't manage your own memory, you should be using a language implementation with automatic memory management. If your code really needs to run "close to the metal", you really need to figure out how to manage your memory. In 2024, language implementations without automatic memory management should be reserved for applications that absolutely need them.
It obviously is a joke, but at the same time it's actually a viable approach for the right problem. Sometimes leaking is very tolerable and in terms of programmer time, very cheap!
> It obviously is a joke, but at the same time it's actually a viable approach for the right problem.
Define "it" here.
Because "just don't free" is pretty different from what's in the post!
Re: Memory leak proof every C program
#126Earlier quoted context omitted.
Using warhead explosion as garbage collector might seem like a clever hack, but all it takes is an upgrade by a different team (say, adding a new engine, or longer-range sensors, or repurposing a surface-to-air missile for a surface-to-surface role), and suddenly your guidance software runs out of memory before it explodes, and your missile falls onto an an elementary school or hospital.
Related: the Ariane 5 rocket failed on its maiden flight because it reused code from its predecessor, which made an assumption that didn't apply to the higher-performance Ariane 5. https://en.wikipedia.org/wiki/Ariane_flight_V88
Seems like a mitigation for this kind of issue would be to simulate the inputs to the system for the expected flight duration.
Re: Memory leak proof every C program
#127This is the core idea: > It is [...] entirely optional to call free. If you don’t call free, memory usage will increase over time, but technically, it’s not a leak. As an optimization, you may choose to call free to reduce memory, but again, strictly optional. This is beautiful! Unless your program is long-running, there's no point of ever calling free in your C programs. The system will free the memory for you when…
Not calling free can bite in short running programs also if memory allocation is done in a loop.
Re: Memory leak proof every C program
#128Earlier quoted context omitted.
A lot of game engines do this, avoiding the cost of a malloc lookup by just allocating everything as a stack
Seen some audio engines that do this too. You can come up with an elegant non-blocking lock free allocator and pass updates from the user thread out to system and reserve the memory, or you can just up front allocate everything that's needed. If it's a fixed function synth, sometimes just allocating everything up front makes more sense.
Kernel drivers, too. Especially the DMA buffers for devices that don’t support scatter gather: if you don’t allocate them at driver startup, you might not be able to find enough free contiguous regions later. Although maybe that’s not as big of a deal these days, since both Windows and Linux can relocate physical pages.
Re: Memory leak proof every C program
#129I have a much better and practical solution: https://github.com/LibreDWG/libredwg/blob/7d9fc3da44bbdb60a4...
#ifdef HAVE_VALGRIND_VALGRIND_H
if (RUNNING_ON_VALGRIND)
#endif
free_all()
Perl5 does its final destruction similarly, only when it has important destructors (like IO, DB handles and such) to call.
Re: Memory leak proof every C program
#130To avoid an bugs, you can add a `exit(0)` at the beginning of your program.