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

[Behdad Esfahbod <behdad cs toronto edu>]

On Wed, 25 Jan 2006, Tim Janik wrote:

> > """
> > gc-friendly
> >
> > Newly allocated memory that isn't directly initialized, as well
> > as memory being freed will be reset to 0.
> > """
>
> yes and no. i've had the same thought when copying over the description
> from macros.txt. but it doesn't address g_malloc() particularly which
> doesn't do this, for other code portion, the 0ing is actually true, i.e.
> GArray (and in the future there can be others).

So maybe the docs can be improved still :).

> >>> 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.
> >
> > Right, but glib doesn't do malloc/free on every
> > g_slice_new/g_slice_free, unless G_SLICE=always-malloc.
>
> yes, that's still not a reason for --with-valgrind, at least i
> don't see it ;)

Like it was already answered.  To be able to announce memory as
freed or allocated when reusing memory.  Like in GArray and
g_slice.  One cannot get that level of accuracy in checking with
valgrind currently, like out-of-bounds array accesses in GArray.


--behdad