[Webkit-unassigned] [Bug 33590] [GTK] GObject DOM bindings

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Feb 1 07:27:23 PST 2010


--- Comment #30 from Christian Dywan <christian at twotoasts.de>  2010-02-01 07:27:20 PST ---
(In reply to comment #29)
> (In reply to comment #28)
> > > 
> > > gchar* and char* are exactly the same thing, one is just a typedef for the
> > > other. The functions return UTF8-encoded NULL-terminated char arrays, that need
> > > to be freed manually.
> > 
> > There is a subtle difference. g_strdup may be using a different memory
> > allocator, such as GSlice, as opposed to strdup. So using gchar* for the return
> > type makes it clear that g_free rather than free should be used to release the
> > memory.
> When inside a glib/gobject project all memory should be freed using the glib
> functions, g_free, g_slice_free, etc. This is IMHO an orthogonal issue wrt
> whether you use 'gchar' or 'char', which are identical and basically considered
> bad ideas even by the people who first thought it was desirable to introduce
> extra names like that when portability is not an issue. We could, and probably
> should, stop using 'gchar' or 'gint' inside WebKitGTK+, and you'd still need to
> use g_free to free our strings, so the idea that this is somehow related to
> what name you use for your types is not correct IMHO.

This is not correct. If memory is allocated using Glib, it needs to be released
using Glib. Otherwise you can end up trying to free something with an allocator
unaware of that memory. Think of xmlGetProp/ xmlFree or sqlite3_malloc/
sqlite3_free which have the same requirement.

Arguably gchar is "just" an alias. But if used consistently it can serve as a
reminder to use the correct memory functions.

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list