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

[Bakul Shah]

On Tue, 06 Feb 2018 18:39:13 -0500 Ken Hornstein <address@hidden> wrote:
Ken Hornstein writes:
> >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:
> 
>       http://www.hboehm.info/gc/
> 
> 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
> negatives.

All valid points. Thanks for explaining.

The way I interpret this: Getting rid of leaks is where gc can
help the most but given short program life, even leak
detection is not a critical issue while gc use has other
downsides.

On creating a library of routines for other programs, that is
worth it only for things where performance is critical (for
other uses access via popen() may be good enough). Such a
library can be written such that  it can be used from program
that use gc or not. BTW, gc can be used for leak detection too
(not sure how it compares with valgrind).