Re: PATCH: anti memleak part 1

[Ali Akcaagac <ali akcaagac stud fh-wilhelmshaven de>]

> > +
> > +    if (abc != NULL)
> > +	g_free(abc);
> > +
> > +    if (name != NULL)
> > +	g_free(name);
> > +
> > +    if (path != NULL)
> > +	g_free(path);
> > +
> > +    if (host_name != NULL)
> > +	g_free(host_name);
> > +
> > +    if (base_dn != NULL)
> > +	g_free(base_dn);
> > +
> 
> OK first of all you don't need to test if a pointer is !=NULL before
> applying g_free() on it, indeed g_free is just a no-op on NULL-pointer.
> Second you assign to eg name different pointer that are result of different
> functions then you g_free it. I think you should g_free it each time you've
> finished with what you've assigned to it (in case the result of the
> function is a newly allocated buffer, that is not allways the case).
> 
> So the rule is : I assign a newly allocated buffer to a pointer (could be
> result of a func call), I do what I want to do with it, when I'm done I
> g_free it before I need the pointer for another allocation.

well, yes i actually am reading more specs of glib and glibc way of
freeing chunks of memory, indeed what peter, pawel and you say is
right. i keep comming from older languages where i was used to check
if there is memory allocated before freeing it i was used to check
if the pointer is allocated or not before freeing memory, which usually
caused in segfault (or just plain crashes)

well agreed that i didnt take much care about the stuff i did with the
search of memoryleaks, my main intention was to SEARCH for it, offer
some stuff and hope that someone reviews it, THINK with me together if
the solution is suitable and then do something with it. there are a lot
of parts in the code where i had the feeling of stuff beeing not freed
correctly, this doesnt include that i am always right. on the otherhand
i havent thought that i pissed people off here with this. at least as i
get the reactions for it. it was only meant to do something and get things
going nothing more nothing less.

i am currently reading more plain glibc and glib specs here to avoid later
trouble with such things...

besides thanks for your comment.

-- 
Name....: Ali Akcaagac
Status..: Student Of Computer & Economic Science
E-Mail..: mailto:ali.akcaagac@stud.fh-wilhelmshaven.de
WWW.....: http://www.fh-wilhelmshaven.de/~akcaagaa