I totally thought this was an April fools joke at first. Why is this front page?
Memory leak proof every C program
11–20 of 175 posts
Re: Memory leak proof every C program
#12If only I had known this earlier in my career! They should really add a feature to make a hard copy of the big bucket list to minimize memory overhead, though.
Re: Memory leak proof every C program
#13I bet this is what some people on my team would come up with if the ticket acceptance criteria said "program must not leak memory when checked with valgrind"
That sounds painful. Unfortunately, I know the feeling.
Re: Memory leak proof every C program
#14I'm concerned about how a non-zero number of people here on HN seem to think this is meant seriously.
Re: Memory leak proof every C program
#15[flagged]
U+1F926 U+200D U+2640 U+FE0F
Re: Memory leak proof every C program
#16This 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…
[flagged]
Re: Memory leak proof every C program
#17Thank you for playing Wing Commander!
Re: Memory leak proof every C program
#18I bet this is what some people on my team would come up with if the ticket acceptance criteria said "program must not leak memory when checked with valgrind"
Goodhart's Law[1] in action!
Re: Memory leak proof every C program
#19This 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…
> There are already tools to identify memory leaks, such as LeakSanitiser https://clang.llvm.org/docs/LeakSanitizer.html. Use those instead.
Clearly the author of TFA is aware of such tools, since the idea is to trick them.
Re: Memory leak proof every C program
#20This 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…
[flagged]
It’s definitely inelegant. But I wouldn’t say it’s entirely without merit.
If you’re writing a very simple “sed” like utility then you could probably get away without freeing.
That all said, the kind of problems were freeing becomes complicated is generally the kind of software that is more complex than your typical “sed” command. So the advise of not freeing doesn’t really address the domain where freeing is a risk.