Re: memory allocation/freeing

[Owen Taylor <owt1 cornell edu>]

Jay Painter <jpaint@serv.net> writes:

> > Just a near by question. 
> > The function gtk_clist_set_row_data(..., gpointer data) just stores
> > the pointer in the clist, and if I understand you right it should
> > copy the "unknown" object (would need the length) or it should
> > take a reference counted object as parameter?
> > 
> > There exists a memory leak in the fileselection dialog because this
> > odd behavior (the clists dir_list and file_list will be populated
> > with data from gtk_file_selection_populate but the clist-destroy
> > functionality nor the file_selection-destroy functionality will
> > free the data in the list.
> 
> This problem needs to be addressed in the filesel dialog; clist should
> never try to do anything with its data.  It might be true there needs to
> be a easier way to run a function on all the data pointers in a clist to
> help solve this problem.

The correct solution is probably that gtk_clist_set_row_data
should have a _full() variant:

gtk_clist_set_row_data_full (..., gpointer data, GtkDestroyNotify *notify)

Where 'notify' is a function that will be called when 'data' is
no longer stored.

i.e., it could be used like

  gtk_clist_set_row_data_full (..., 
                               g_strdup ("Some Text"), 
	  		       (GtkDestroyNotify *)g_free);

This is the standard way the GTK deals with opaque pointers. It
could be argued that the row_data in a CList is generally 
homogeneous, so memory could be saved by only having a single
DestroyNotify function for the whole list, but I think the
per-row solution is more consistent with the rest of GTK, and
slightly more flexible.

Regards,
                                        Owen