[Glade-devel] small patch

[sridharinfinity yahoo com (Sridhar R)]

--- Paolo Borelli <pborelli katamail com> wrote:

> > > > ***
> ../../glade3.orig/src/glade-signal-editor.c
> > > Mon
> > > > Jan 12 21:38:09 2004
> > > > --- glade-signal-editor.c       Mon Jan 12
> > > 22:04:06
> > > > 2004
> > > > ***************
> > > > *** 158,161 ****
> > > > --- 158,162 ----
> > > >         GtkTreeIter *parent = NULL;
> > > >         GList *list = NULL;
> > > > +       GtkTreePath *path_first = NULL;
> > > >         GladeWidgetClassSignal *signal;
> > > >     
> > >
> > > No need to initialize local vars to NULL as far
> as I
> > > can see, while you
> > > are at it remove it also from the other vars;
> > > beside, not related to
> > > your code, but usually a TreeIter is allocated
> on
> > > the stack: i.e.
> > > GtkTreeIter iter;
> > > gtk_tree_functio (..., &iter, ...);
> >
> >    I don't understand.
> About the variables declaration you can omit the "=
> NULL;".
>
> About the treeiter: I took a closer look at the code
> and in this case I
> have to admit the using a pointer to the iter is
> correct since
> glade_signal_editor_dialog_append_signal returns a
> iter allocated in the
> heap memory with g_new0. Not your fault, but as far
> as I can see this
> memory is leaked since there isn't a g_free (iter).
>
> In general, if you look at the docs in gtk you'll
> see that most of the
> times, even if the iter is an object, it is used as
> a local variable,
> not as a pointer: i.e. GtkTreeIter iter; this means
> that the memory for
> the object is automatically allocated on the stack
> when the function is
> called and automatically freed when the function
> ends. Of course since
> some of the API need to get a pointer to iter, you
> pass them the var
> address, i.e. &iter.
> In our case using this approach would mean modify
> the
> glade_signal_editor_dialog_append_signal function to
> take another iter
> pointer as parameter instead of returning a newly
> allocated iter, and
> pass &parent to it.
>
> Hope this clear things a bit.

  Oh! I got the problem. I should have used 
gtk_tree_model_get_iter_first, instead of the one I
used before.

> > > > ***************
> > > > *** 183,186 ****
> > > > --- 188,193 ----
> > > >         gint response;
> > > >   
> > > > +       g_assert(editor);
> > > > +       g_assert(editor->class);
> > > >         g_return_if_fail
> (editor->class->signals
> > > !=
> > > > NULL);
> > > >   
> > >
> > > Use g_return_if_fail instead of assert to check
> > > function args.
> >
> >   No.  If you have seen my bug report on glade3,
> the
> > program actually segfaults.  But with these assert
> > statement, it shows the correct message as 'assert
> > failure', saving minutes of fiddling up with gdb.
> >   Any thoughts?
>
> g_return_if_fail *are* asserts made exactly for this
> use; when they fail
> they print a critical message on the console and
> then return so that the
> function is not executed.

   But without the above two g_assert statements, the
statement
   g_return_if_fail (editor->class->signals);
  _will_ cause segfault, if either `editor` or `class`
is NULL!

> ciao
>       paolo


=====
Sridhar R 
Email: r_sridhar users sf net
WWW:   http://sridhar.has.it

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus