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

[R0b0t1]

On Mon, Jul 30, 2018 at 10:24 AM, Michael Van Canneyt
<michael at freepascal.org> wrote:
>
>
> On Mon, 30 Jul 2018, Sven Barth via fpc-devel wrote:
>
>> Michael Van Canneyt <michael at freepascal.org> schrieb am Mo., 30. Juli
>> 2018,
>> 15:30:
>>
>>> Obviously provided you don't install another mechanism that does this and
>>> don't raise exceptions manually, which - AFAIK - is the case in the
>>> compiler...
>>>
>>
>> The compiler does use exceptions when the compilation needs to be aborted
>> e.g. when too many errors occurred or an internal error is encountered.
>
>
> This is bad news, because it in effect means that the try/finally is
> necessary
> if people want to fix memleaks :(
>
> This will considerably slow down the compiler.
>

I would very much like to see the compiler usable as a dynamic
library. Compartmentalizing the bulk of the code in this manner might
aid readability and comprehension even if it is not immediately wise
to actually use the shared object in a third party application due to
memory leaks.

I wouldn't mind running some static analysis on FPC in an attempt to
get rid of memory leaks. It's fairly mechanical and probably a good
introduction to the codebase. This page[1] is promising as it
indicates valgrind should work well on FPC binaries (I didn't have
much a reason to expect otherwise, but you never know).

Is there any reason this hasn't been done? What could raise statements
be replaced with if they must be replaced?

Cheers,
    R0b0t1

[1]: http://wiki.lazarus.freepascal.org/Profiling