The potential memory leak was more to do with how resolvers may
implement this as it relies on the resolver freeing the memory of the
array it returns. As done in liblouis-java the Java GC does this, but in
C applications it may be more difficult due to no GC in C. How might one
prevent the memory leak and does the default liblouis resolver deal with
this correctly?
Then there is the issue of Java's GC potentially being too aggressive
and releasing memory before liblouis has the chance to copy the result.
My thought is that whilst both of these are issues for the resolver
implementation to deal with, the API does not help one get it right and
not hit one of these issues. This is why I feel may be it is a liblouis bug.
There is another way I can think of doing this which may encourage
better memory management. Instead of returning an array of the files,
may be the resolver could work by yielding results one by one and
liblouis keeps calling the resolver until it gets no more results (a
NULL value), or if you prefer a separate function to check if there is
more (I guess all a bit like an Iterator in Java). In these later calls
checking for more data the old return values could be freed by the
resolver. I know requires a LibLouis API change but I think it is better
than the other options due to using a standard pattern (iterator) and
encouraging better memory management by making it simpler to do it correct.
For a description of the software, to download it and links to
project pages go to http://liblouis.org
