Re: changing --enable-gc-friendly=yes semantics

[Tim Janik <timj imendio com>]

On Wed, 25 Jan 2006, Behdad Esfahbod wrote:

> On Wed, 25 Jan 2006, Tim Janik wrote:
>
> > as suggested earlier this week to matthias, i've now introduced
> > G_DEBUG=gc-friendly in CVS. this is compiled unconditionally into
> > GLib, so with the next development release, it'll be usable for
> > all glib applications to 0-out released memory.
>
> Humm, is it true that gc-friendly makes valgrind not err about
> uninitialized access memory problems?  Since you are zeroing
> malloc()ed memory, right?  And g_slice_ doesn't return memory
> anyway.

no, and no.

gc-friendly does *not* turn g_malloc() into g_malloc0(), it just
zeros the memory passed in to free().
and g_slice_alloc()/g_slice_new() does of course return memory (newly
allocated), since it's an allocator API.

> Guess we should add a compile-time --with-valgrind option and add
> some valgrind hooks to glib memory functions.

what for? i can't see any need for that. especially since valgrind
correctly hooks the systems malloc/free calls anyway.

> > this changes the --enable-gc-friendly=yes semantics slightly,
> > instead of enabling the compilation of gc-friendly code portions,
> > it now changes the glib default for gboolean glib_mem_gc_friendly;
> > from FALSE to TRUE.
>
> Any way to turn it off using the env var?  G_DEBUG=no-gc-friendly
> pops to my mind...  Same for other settings too maybe?

well, that could be added, but i suppose the use case is very rare,
why would you configure glib with --enable-gc-friendly=yes and then
start apps with G_DEBUG=no-gc-friendly? (not-gc-friendly, gc-unfriendly, ... ;)

leaving --enable-gc-friendly in place at all was more of a compatibility
decision than anything else. by continuing to support it in glib and
defaulting to G_DEBUG=gc-friendly that way, existing automated testing
frameworks will continue to function as expected.

---
ciaoTJ