On Fri, Jun 26, 2015 at 8:50 PM, Jasper St. Pierre <jstpie...@mecheye.net>
wrote:

> Yeah, we've all been sort of aware of this for some time. I've abused
> it to the fact where I know that malloc and g_new / free and g_free
> will *always* be the same since a specific glib version.
>
> I think removing all the code is fine.
>
> On Fri, Jun 26, 2015 at 8:38 PM, Alexander Larsson <al...@redhat.com>
> wrote:
> > So, I just tried to use the memory profiler in glib, and I crashes
> > really early because the gobject constructor (gobject_init_ctor) calls
> > g_malloc before main() is reached.
> >
> > This means g_mem_set_vtable() is impossible to use. I don't necessarily
> > think this is all that bad. Honestly we should never have made it a
> > vtable (one extra vfunc per malloc...) and instead do memory profiling
> > etc the "normal" way, i.e. LD_PRELOAD something with malloc
> > interceptors. Maybe we should just remove all this code and keep
> > g_mem_set_vtable as a dummy function that prints a deprecation warning?
>

Would it be possible to write a how-to page on the Gnome wiki that the
documentation of the now-deprecated function would point to?

I'm afraid that new developers would be the ones hit hardest by this. I
certainly used g_mem_set_vtable to my benefit when I was first starting out
with the Gnome stack. I could now figure out how to do memory profiling the
"normal" way, as you say, on my own, but I certainly wouldn't have been
able to 8 years ago.

Regards,
-- 
Philip
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Reply via email to