Ken Hornstein wrote:
First off .. normally MH memory management has been terrible, because the
programs are all short-lived. This makes it hard to do some interesting
long-term things, like create a set of library routines for other programs
to use. This is all part of cleaning that up so maybe we could do that
sometime in the future.
since we have a unit test suite, perhaps we should add valgrind there.
I am kind of concerned about embeddeding that library, as the GC library
is not portable. So we'd have to teach our autoconf to select the
right os-specific bits (and I took a look at it, and there is a LOT
of os-specific stuff in their autoconf script). We'd have to take a
dependency on that, and I'm not sure if we could still have a library
usable by third-party programs. It would also destroy any hope of
our goal of being portable to any POSIX platform.
i want to be sure you know you just said "we want MH to run on older
operating systems, not just the ones being installed today and in the
future." even microsoft's windows 10 ubuntu thingie can handle hboehm.
in the broader context of our work, we might ask, do we want the size of
the MH user community to ever again grow, and if so, what will those
users be running, in terms of a common POSIX superset?