Obviously 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.
Memory leak proof every C program
31–40 of 175 posts
Re: Memory leak proof every C program
#32Hahahahaha I love this! Almost as good as fixing race conditions with sleep statements ( which I see a lot )
Re: Memory leak proof every C program
#33This 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...
Re: Memory leak proof every C program
#34From the comments I get the impression that we have all worked with someone that would have considered this an actual solution and we had to talk them out of it.
Re: Memory leak proof every C program
#35This 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…
The Zig compiler does this on purpose in some cases, iirc. Free can be a waste of time if the program is going to die in half a second from
now.
Re: Memory leak proof every C program
#36This 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…
Hilarious!
But I remember the first time I saw such a program which never freed anything: jitterbug, the simple bug tracker which ran as a CGI script.
It indeed allows a very simple style!
Meanwhile, use ccan/tal (https://github.com/rustyrussell/ccan/blob/master/ccan/tal/_i...) and be happy :)
Re: Memory leak proof every C program
#37This 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…
[deleted]
Re: Memory leak proof every C program
#38While subtle, your point was not lost on me!
Technically all pointers are accessible, but the issue remains that we have not logically accounted for unused resources and are wasting capacity. In this sense, memory leaks are possible in all languages. We could store every object into a global structure, and it will never be freed in any language. Thus, my Rust program balloons forever.
Re: Memory leak proof every C program
#39I've got an idea...
We have a counter that goes up by 1 every time you call malloc.
And down by one every time you call free.
And when the program quits, if the counter isn't zero, an email is fired off and a dollar gets sent from the developers bank account to the users bank account...
Re: Memory leak proof every C program
#40Obviously 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!