Date: Wed, 25 May 2022 02:57:52 +0200
From: "Bruno Haible via austin-group-l at The Open Group"
<austin-group-l@opengroup.org>
Message-ID: <5462894.CAdn2TfLgq@omega>
| IMO, it's useful to distinguish bounded and unbounded memory leaks:
| - A _bounded_ memory leak is one where the amount of leaked memory is
| bounded by an a-priori computable constant.
| - An _unbounded_ memory leak is one where such a bound does not exist.
Personally I would first determine whether there is a memory leak
at all. For this I like to imagine that we are using a garbage
collecting memory allocator ( no equivalent of free() ) and ask
whether such a system would reclaim any memory that has not
been subject to free() whike using C memory management.
Alternately, can the memory be reached by following pointers
from some visible starting point (whether in the app, or some
library does not matter). If so, it is not leaked, even if
never free()'d.
If those tests do show a leak, then the above tests can help
determine if it matters or not.
But from your description, I'd assume (guess perhaps) that there
is no leak at all in what you have described, in which case that
classification scheme is irrelevant.
I would also guess that a side effect of the way it was described
is that changes to the on disc backing store (the .mo file, or
whatever) will not be detected while the application remains
running, and that aside from execing itself to restart clean
there is no way for an application designed to run forever
to ever see updated data.
If that's not the case, then given the guarantees you seem to
be making about the lifetime of returned pointers, it looks
like a memory leak would be unavoidable. Consider one thread
which does gettext() after which you have no idea when it
might use that pointer again, while another keeps changing,
and then causing to be loaded, the altered data. Forever.
kre
