Edward Bartolo <edbarx@???> writes:
> Hi Rainer Weikusat,
>
> This is what valgrind says:

[...]

> ==15914== LEAK SUMMARY:
> ==15914==    definitely lost: 136 bytes in 12 blocks

[...]

> ==16064== LEAK SUMMARY:
> ==16064==    definitely lost: 141 bytes in 13 blocks

[...]

,----
| A program is said to 'leak' memory when it loses track of some memory it
| allocated (from the heap) because the last pointer pointing to it is
| overwritten without the memory being returned to the heap first. After a
| process existed, its address space is torn down and any real memory
| allocated by the kernel to cover for some used virtual memory will be
| reclaimed.
`----

Eg, one of these memory leaks is that the read_interface_defn routine
reads lines of text into a dynamically allocated buffer whose address is
stored in a local variable. This functions is called once for reading
every interface file and it loses an allocated line buffer for every
call. But since that's very small (the length of a line), there's no
risk that this will ever cause the program to run out of memory while
reading interface files, eg, it would need to read 13,107 files in order
to leak 1M.

Considering that this is decidedly "I'm a genius who conquers the
chaos!" code, I'm not overly surprised that the chaos conquered the
genius as writing code which is so complicated that the author itself
loses its grip on it is very easy but while this makes a somewhat good
argument in a halfway philosophical discussion about 'sensible code
architecture', it's nothing to worry about.