Memory leak proof every C program

Post by _a_a_a_ » Sun, Jan 21, 2024, 11:52 PM UTC

Dylan16807 wrote: post #170

_a_a_a_ wrote: post #148

Earlier quoted context omitted.

Yes. Hence the word 'joke' I used. For short running programs, it's fine. The longer running programs you can often find a few places where 95% of the leaks happen and easily 'free' those leaving the last 5% to leak slowly. It depends. Just remember it's a valid solution sometimes.

I still don't understand. The joke and the sometimes valid solution are different strategies . The joke only reminds people of the valid solution. It feels like multiple people are giving the article the briefest skim and assuming the two are the same. Perhaps focusing on the words "optional to call free" and extrapolating off that without looking at the code or properly reading the rest of the text. Unless I'm badly…

Post by erik_seaberg » Tue, Jan 23, 2024, 1:33 AM UTC

Karellen wrote: post #150

erik_seaberg wrote: post #139

Earlier quoted context omitted.

This is like going back to malloc and free but using array indices rather than pointers, and each type has a fixed-size heap. We did it in one Microsoft service because the very first .NET releases had slow GCs.

One could argue that pointers are just array indices, where the array is your whole address space, and you only get the one array for all your types.

Post by fsckboy » Thu, Jan 25, 2024, 2:45 AM UTC

ric2b wrote: post #160

fsckboy wrote: post #122

Earlier quoted context omitted.

it's not funny, it's not obvious and it's wasting a lot of people's time. ha. ha. ha.

It's quite obvious... "If you don’t call free, memory usage will increase over time, but technically, it’s not a leak."