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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Feb 1 07:36:40 PST 2010


https://bugs.webkit.org/show_bug.cgi?id=33590





--- Comment #31 from Xan Lopez <xan.lopez at gmail.com>  2010-02-01 07:36:36 PST ---
(In reply to comment #30)
> > 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.

This is exactly what I meant. When using glib in a project most/all of your
functions will use the allocation functions from glib, so in the common case
you'll have to use the corresponding release functions, regardless of your
style preference between 'gchar' and 'char'.

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

I don't agree that we need to do this to be constantly reminded that you have
to use 'g_free' to free strings instead of simply 'free'. That should be the
default assumption (certainly we don't document it all over the place), and
special care should be given, documentation-wise, to the cases where for some
reason this cannot be done (like, for example, if we need to return strings
allocated by different libraries).

In any case I'm reasonable sure that this not the origin of the 'gchar'
typedef, whether or not some people choose to use for that purpose is another
issue.

Also, this is offtopic in any case. For now I'll use gchar everywhere since
that is our current style, we can discuss whether or not we want to change in
the future.

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