Especially when tools like valgrind, dr. memory, gperftools exist. When I write C code, I write tests for most non-trivial shit. After I compile, I run valgrind. Boom. Immediately I know to fix a mem leak before it gets out of hand and too hard to trace.
Can it be true? Are mem leaks purely due to programmer laziness? Too fucking lazy to run a small piece of software LMAO. Go fuck yourselves.
Name:
Anonymous2016-01-16 3:32
most coders are fucking retards, if you wrote up how you work and do all this as a nice blog post it would be really useful.
Name:
Anonymous2016-01-16 5:33
The closest thing to a no-gc memory-safe language is Rust and it's an awful mess created by communist zealots at Mozilla.
Name:
Anonymous2016-01-16 6:32
I don't know I use Python I never get memory leaks lol
Name:
Anonymous2016-01-16 6:34
>>4 You always leak. The difference is that your leaks get cleaned up at the cost of overhead.
Name:
Anonymous2016-01-16 7:26
Hahahahahahahaha How The Fuck Are Memory Leaks Real Hahahaha Nigga Just Call free Like Nigga Use Static Analysis Haha
Name:
Anonymous2016-01-18 12:25
DYNAMIC ALLOCATION IS BAD
YES IT IS BAD
IF YOU USE MALLOC/NEW AND FREE/DELETE AT RUNTIME, YOU ARE A BAD PROGRAMMER
Name:
Anonymous2016-01-18 12:35
>>7 1.you obviously don't write programs larger than a few pages 2.modern malloc is fast and reliable 3.the allocations can be timed to reduce performance impact. 4.if you really need a custom allocator don't invent wheels: there are special purpose allocators and structures debugged, benchmarked and unit-tested already. 5.you are going to ignore the above and write crappy allocator when you finally need one, because everything else is too mainstream.
Name:
Anonymous2016-01-18 12:44
>>8 Wrong, do you see many Ada programs using malloc? I don't think so.
Name:
Anonymous2016-01-18 13:13
>>8 1. I do, always use custom allocators and efficient memory pools 2. No, it is extremely dependent on OS 3. Can't time real time applications like high performance databases or games 4. It is always waste of time to write a module from scratch if there is already popular one with BSD-like license. If you are on embedded platform, maybe you have to write a custom one. 5. xd
For example, in following code that is simple fibs-implementation, there actually is one when calling fibstst function, even though free is called. It makes sense to use garbage collection to fix the problem, since it's practically impossible for human to see all the problems.
unsigned long long int * fibs ( unsigned long long int * SequenceNumber ) { if (*SequenceNumber <= 0) { unsigned long long int * Result = 0;
Result = malloc ( sizeof ( unsigned long long int ) ) ;
memset ( Result , 0 , sizeof ( unsigned long long int ) ) ;
return ( Result ) ; }
* SequenceNumber = * SequenceNumber - 1 ; unsigned long long int * PreviousNumber = fibs ( ( * SequenceNumber ) ) ;
* SequenceNumber = * SequenceNumber - 1 ; unsigned long long int * PreviousOfPreviousNumber = fibs ( * SequenceNumber ) ;
unsigned long long ResultOfArithmeticOp = * PreviousNumber + * PreviousOfPreviousNumber ;
unsigned long long int * FinalResult = malloc ( sizeof ( long long int ) ) ;
memcpy ( FinalResult , & ResultOfArithmeticOp , sizeof ( unsigned long long int ) ) ;
return FinalResult ; }
int tstfibs(int n) { int ptr = fibs(&n); int res = *ptr; free(ptr); return res; }
Name:
Anonymous2016-01-18 15:35
>>11 Fuck you, I was going to get the dubs. Not you.
Name:
Anonymous2016-01-18 19:21
>>12 You shouldn't write this shitty piece of code in the first place.
Name:
Anonymous2016-01-18 19:53
>>14 What are you talking about? That's an efficient fibs implementation in very idiomatic C.
Name:
Anonymous2016-01-18 20:50
>>12 The problem should be obvious though. You are making n allocations, but only freeing once. This should be easy to find with the space complexity when creating the correctness proof.
Name:
Anonymous2016-01-19 1:37
>>12 There's a memory leak in fibs, not in tstfibs. tstfibs doesn't make any fucking sense. Why are you dereferencing and freeing an int?
There is a very simple way to prevent for memory leaks: Check if the used procedures allocate, and if they do, ensure the memory is freed at the end. That's all.
Name:
Anonymous2016-01-19 8:51
>>17 The problem is that the C compiler happily compiles that without any issues. It is practically impossible for human to find any issue in there.
Name:
Anonymous2016-01-19 11:02
QURAN CODE GET
Name:
Anonymous2016-01-19 13:50
>>18 Impossible? You're either trolling or retarded.
Nice argument there. Maybe if you provided some reasons, we could take you seriously. The fact is there is a memory leak in that `fibs` and there's no easy way to find out where.
Name:
Anonymous2016-01-19 15:54
>>21 It's immediately obvious that your allocations and frees aren't paired up. This is 101 level shit that any competent teacher should have drilled into your thick skull.
Name:
Anonymous2016-01-19 17:44
KING OF DUBS
Name:
Anonymous2016-01-19 17:44
>>22 Nice dubs there. MAybe if you provided some checking, we could take you seriously. The fact is that you got dubs and there's no easy way to check 'em.
Name:
Anonymous2016-01-20 7:39
>>18 The problem is that you are an idiot who can't follow simple rules.
Does fibs use allocating functions? —(yes, malloc)→ Does it always free the memory? —(no)→ fibs is an allocating function. Is all memory allocated within fibs reachable in the end —(no, inner fibs calls allocate but aren't freed)→ fibs leaks.
Don't use C if you are too stupid for basic things like these.
Name:
Anonymous2016-01-20 12:29
>>25 Look, it's easy to see that you are right. But the fact is it basically took you two days to find the issue. The problem is in C language. Not the programmer.
Name:
Anonymous2016-01-20 13:04
>>26 You should consider yourself lucky that I got around to it so quickly!
unsigned long long int unsigned long long int unsigned long long int
Please fuck yourself with a broomstick for this awful shit code.
Name:
Anonymous2016-01-20 14:38
>>28 For portability reasons it is better to use `unsigned long long int` rather than `unsigned long int`, since `unsigned long int` might be only 32-bits on some platforms.