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-18 15:07
Memory leaks aren't that easy no notice.
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; }