[Top] [All Lists]

Re: [Nmh-workers] GCC 8 pre-releases have escaped...

2018-02-06 17:39:38
Have you guys considered using the Boehm-Demers-Weiser
conservative GC?  Then you can just use strdup(), strndup(),
asprintf(), replace char[] vars with char* vars and let the
garbage collector worry about cleaning things up. Seems much
simpler than adding functions such as uvstrncpy, turnccpy. 
trunccpy() is strndup().

My first inclination is that we should stick with the traditional model
of C in terms of explicit allocation/deallocation.  But!  Maybe that's just
me being an old fogey, so why not take a look at it?

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.

Now in terms of implementations, I assume you're talking about:


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.

So while I'm not opposed to the idea, it just seems like it would be
a lot of complicated hair for a small gain and would have a bunch of



<Prev in Thread] Current Thread [Next in Thread>