[Glade-devel] small patch
Sridhar R
sridharinfinity@yahoo.com
Wed, 14 Jan 2004 01:56:57 -0800 (PST)
--- 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