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

[Behdad Esfahbod <behdad cs toronto edu>]

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.

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

> 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?

> the changes are reflected in docs/macros.txt and in the online docs:
>    http://developer.gnome.org/doc/API/2.0/glib/glib-running.html#G_DEBUG
>
> ---
> ciaoTJ

Cheers,

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
	-- Dan Bern, "New American Language"