Re: Glib: a Win32 discussion

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

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:

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]