GtkCList sending select_row on non-existent row

[John Sullivan <sullivan eazel com>]

I traced a segfault in Nautilus
(http://bugzilla.eazel.com/show_bug.cgi?id=7846) down to some fishy
GtkClist behavior, which I believe was introduced fairly recently, since
this Nautilus bug seems like it would have been noticed long ago
otherwise.

The fishy behavior is that when the last row is removed, real_remove_row
still emits a SELECT_ROW signal, with the selected row set to 0. But of
course there is no row 0. I had an assert in Nautilus that failed a
parameter check due to this mismatch, hence the crash. I can make
Nautilus not crash here, but I'm not sure what to do about GtkCList.

The code that's sending the SELECT_ROW signal is this, with a little
preceding code also quoted (This is in the stable branch, gtk-1-2):

  /*if (clist->focus_row >=0 &&
      (row <= clist->focus_row || clist->focus_row >= clist->rows))
      clist->focus_row--;*/

  if (row < ROW_FROM_YPIXEL (clist, 0))
    clist->voffset += clist->row_height + CELL_SPACING;

  if (clist->selection_mode == GTK_SELECTION_BROWSE && !clist->selection
&&
      clist->focus_row >= 0)
    gtk_signal_emit (GTK_OBJECT (clist), clist_signals[SELECT_ROW],
		     clist->focus_row, -1, NULL);

That commented-out hunk of code sure looks relevant, but it was
commented out long ago (November 1998). There's is no code in
real_remove_row to change the focus row, so if it was the only row
before (0), it will still be 0 here, and the signal will be sent with 0,
which is wrong since row 0 does not exist.

Am I right to think that sending a select_row signal on a non-existent
row is a GtkCList bug? Or should I just make Nautilus robust to this and
live with it?

John