[fpc-devel] compile time memory leak detection

[Nikolai Zhubr]

20.01.2010 0:22, Marco van de Voort:
> Totally different issue. The problem is that there was no implementation
> of memavail that would suit the usage of memavail in old dos code.
>
> That was the simple difference between single- and multiprocessing, which
> was ingrained in the use.  Even the simple showing available memory like
> Turbo Vision apps sometimes did would lead to strange behaviour (one minute
> it would look like memory was running low, and then later when an additional
> block was allocated from memory, there would be plenty free memory again)
>
> It would become even more confusing when you tried to make decisions based
> on it. (like trying to allocate a big as possible block to be used as
> cache).  When one would let memavail return the memory available in the heap
> currently allocated it was too little. If you'd let it return the memory
> globally available, your risk starving other apps for memory (*), and
> allocating huge chunks to former 64k apps that won't use more than a few
> 100ks.
>
> There was really no solution then.
Well, you are right of course. I just meant that a sole existance of 
some code relying on some feature does not necessarily prove this 
feature is sane enough for all times.
Standard pointer arithmetics is not inherently broken as memavail. It is 
even usefull. However, a small mistake in such code also leads to 
strange behaviour, and we humans tend to sometimes make mistakes...

>
> (*) not to speak of the fact that a lot of systems returned virtual memory
> as free memory.
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
>