Re: [gtk-list] Bug in gtkclist: cell_set_text and friends.

[Tim Janik <timj gtk org>]

On 11 May 1998, Rob Browning wrote:

> 
> In the copy of gtkclist.c I have, cell_set_text cell_set_pixtext, and
> perhaps others all free the current string before storing the new
> one.  This makes the following code segfault:
> 
>   gtk_clist_get_text(cl, row, col, &text);
>   ...
>   gtk_clist_set_text(cl, row, col, text);
> 
> Is this intentional?  It seems reasonable to have gtk_clist_set*text()
> check to see if the string argument is the same pointer the one
> already in the cell.  If so, then it shouldn't try to free it.

there are a *lot* of places in gtk that will produce a segmentation fault
with code like this. really checking for new_pointer!=pointer wouldn't
always do the trick imagine:

s = _get_title();
if (s &&
    s[0]=='G' &&
    s[1]=='t' &&
    s[2]=='k')
  set_title(s + 3);

e.g. to remove a prefix from title="GtkWindow".
the only save approach is code like:

static gchar *the_title = NULL;

_set_title (const gchar *s)
{
  gchar *old_title;
  
  old_title = the_title;
  the_title = g_strdup (s);
  g_free (old_title);
}


> Now I know that the above code is just a no-op, but aside from making
> the interface more robust, and keeping the user from having to check
> all the pointers carefully, what about the case where you're trying to
> change a cell from text to pixtext like this:
> 
>   gtk_clist_get_text(cl, row, col, &text);
>   gtk_clist_set_pixtext(cl, row, col, text, spacing, pixmap, mask);
> 
> I believe this will also segfault.

basically, consider the data as something private to the object you called
and therefore use g_strdup() before refering the text and passing it into
other functions.
btw, g_strdup (NULL) wil savely return NULL and g_free(NULL) is just a nop.

> 
> Thanks.
> 

---
ciaoTJ