> > On Wed, Sep 20, 2017 at 02:54:31PM +0200, Christophe de Dinechin wrote: > > > > > >> The benefit of doing it that way (in addition to requiring less source > > >> code > > >> changes and making following rebases or merge much easier) is that it > > >> leaves > > >> the option to instrument spice allocations specifically when the need > > >> arises. > > >> > > > > > > There are many tools to instruments memory allocations and is not hard > > > to write one on your own. For instance knowing that objects file takes > > > precedence over libraries you can write a module defining malloc, or use > > > --wrap linker option or LD_PRELOAD. > > > > That works if you want to instrument all malloc calls. If you want to do > > something specific to spice, you can’t do that. > > You could do that with systemtap for example. And I really don't think > we should have our spice_xxx wrappers for library calls. > > Christophe > Another reason for this set of patches is that code is already mixing different macros/functions and every time I write some code I have to check where is freed and so it's easier to write the old style way (whatever is the style of the current source I'm editing). This series try to unify and use only one (with very minor exceptions). Yes, to reduce difference a "#define spice_new g_new" (or similar) may be used but still there would be a mix of spice_new/g_new (the "new" as an example). The only missing function/macro in GLib is spice_malloc_n_m, but is rarely used in the code. Frediano _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel