[fpc-devel] compile time memory leak detection

[Marco van de Voort]

In our previous episode, Nikolai Zhubr said:
> 19.01.2010 23:18, Marco van de Voort:
> > FPC is not going to forbid standard pointer use, since it breaks a lot of
> > code.
> Of course. I think it all was about new features for new code.
> By the way, it reminds me MemAvail (though not exactly the same). Lots 
> of code used to use it, however AFAIK it is not available anymore (for a 
> clear reason that it is inappropriate for any modern code)

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.

(*) not to speak of the fact that a lot of systems returned virtual memory
as free memory.