Re: Glib: a Win32 discussion

[Hans Breuer <hans breuer org>]

At 15.04.2011 12:02, Alexander Larsson wrote:
> On Sun, 2011-04-10 at 12:46 +0200, Hans Breuer wrote:
>
> > > The first thing that should change is making g_malloc and
> > > friends use the HeapAlloc function, and ensure that
> > > g_mem_is_system_malloc() always returns false. This is really easy to do
> > > and shouldn't upset the apple-cart too much.
> > This would break a lot more code than currently is broken. But you can
> > already do this by using g_mem_set_vtable() in your application.
> >
> > > Memory allocation is the easy bit. HeapAlloc maps nicely onto malloc.
> > Not really if there are libraries with CRT dependencies involved.
>
> Hmm, I'm confused here, in two ways.
>
> First of all, what makes switching g_malloc to HeapAlloc useful? Since
> g_malloc must always be paired with g_free which is from the same dll,
> there can never be any multiple-crt issues?
Exactly, the CRT mixing issues are elsewhere, as I tried to outline in
"Getting rid of CRT use in GLib?"
http://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00052.html

> I can see how making g_mem_is_system_malloc return FALSE makes sense
> though, as the definition of "system" here is problematic (multiple such
> versions exists). I'm pretty sure g_mem_is_system_malloc isn't that
> heavily used anyway (found 3 uses outside glib in my full gnome
> checkout), so this would probably not be a problem.
>
> Secondly, Hans, how can such a change break apps?
With current GLib the actual use of malloc/free or any other allocation 
pair is under control of the application developer by g_mem_set_vtable().

Not calling g_mem_set_vtable() at all currently 'guarantees' that CRT 
malloc/free is in use. Using HeapAlloc/HeapFree and always returning FALSE 
from g_mem_is_system_malloc() would indeed disclose allocation pair 
mismatches. But some of them could be intentionally and relying on the 
guarantees above.

> This is a valid setup,
> so any code that is broken by this is already "broken" since it matches
> g_malloc/free and malloc/free without checking g_mem_is_system_malloc.
Admitted, I'm considering to fix the one occurence I introduced in Dia 
becuase of cairo_image_surface_create_for_data(), see:
http://git.gnome.org/browse/dia/tree/plug-ins/cairo/diacairo-renderer.c#n799

> Any such problems should be fixed and freed.
For the mismatch in allocation/deallocation I agree the app is faulty.
But still it currently could work (or even does) for the reasons given 
above. And I consider changing the default allocation is breakin the ABI.

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert