Re: [gtk-list] Re: Freeing data connected to a widget via signals...

[Owen Taylor <otaylor redhat com>]

Matthew D Allen <s2mdalle@titan.vcu.edu> writes:

> >take a look at                      
> > 
> >  guint       gtk_signal_connect_full         (GtkObject *object,   
> >                                               const gchar *name,
> >                                               GtkSignalFunc func,
> >                                               GtkCallbackMarshal marshal,
> >                                               gpointer data,
> >                                               GtkDestroyNotify
> >destroy_func,
> >                                               gint object_signal,           
> >                                               gint after);
> > 
> >where GtkDestroyNotify is
> >
> >  void        (*GtkDestroyNotify)             (gpointer data);
>  
> Worked like a charm, thanks.  (Well, after a bit of experimenting, anyway)
> It's always nice to locate and fix those 400KB memory leaks.  :)  (aaaah!)
> 
> Now pretty much the only other memory issue I have with GTK+ is how and
> when it chooses to allocate new memory for the purpose of returning a
> value.  I.e. if you do gtk_editable_get_chars() it returns dynamically
> allocated memory, which you have to g_free() after you use, but with some
> other widgets, you really shouldn't free the result of functions that
> return the widget's "contents" because instead of newly allocated memory,
> it's just returning one of the widgets fields.  I tend to think of it
> conceptually, as in, "this function returns malloc'd memory when you ask
> for the contents of the widget, and here's a similar function (different
> widget) that doesn't return malloc'd memory (or at least not memory you
> should free)".  Conceptually, they're both functions that "return
> something that's 'in' the widget".
> 
> Any chance of those types of things ending up in the RDP?  (generally,
> when I free the return value of a GTK+ call when I'm done with it, I only
> did it because I checked out the gtk+ source and saw that it was
> g_strdup'ing a value on return.  Something like
> return(g_strdup(widget->field));

Look at the GTK+ RDP entries for gtk_editable_get_chars() and 
gtk_entry_get_text(). If this information isn't in the RDP for
a (documented) xfunction where it is relevant, than please let us know.

The basica policy is that all new GTK+ functions added will duplicate
strings on return, but there are still old legacy functions we can't
change.

Regards,
                                        Oewn