[fpc-devel] Why/how does the compiler have a non-trivial numberofmemory leaks after over two decades of development?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Mon, 30 Jul 2018, J. Gareth Moreton wrote:

> I would say that that's a little naïve and dangerous to think like that.
> Sure, Windows might have the means to clean up memory after an
> application terminates, but not all platforms have such heap
> deallocation features (e.g. pure DOS, where certain procedures and
> interrupts remain in memory even after the application terminates...
> so-called memory-resident programs).

While I generally agree, in practice it's usually a non-issue.

Pure DOS, as in the 16bit target is not supported to run the compiler,
only via GO32V2, and having DPMI TSRs is... well... :)

On Amiga and similar systems, AROS, MorphOS for example, which indeed does
not free up the memory after a program terminates, I implemented a memory
pool in the FPC RTL, so all memory is freed anyway during the program's
exit. Any application which wants to go beyond this behavior for whatever
of its own reasons is free to use the OS allocation functions directly, or
implement its own memory manager. The same with open files on this
platform, actually, which wouldn't be closed without the RTL taking care
of them. And I also have to manage our own stack, and lets not even
mention threading... :)

The sideeffect is, that this approach silently "fix" the compiler's own
leaks too, so FPC remains useable on these systems. In general it is much
safer anyway, because expecting all the broken code out there to get fixed
for such systems is sadly just naive.

Having this said, anyone who still fixes leaks win the compiler will be my
hero! :)

Charlie