On Mon, Mar 25, 2013 at 7:59 PM, Dan Gora <[email protected]> wrote:
[...]
>> 1] check whether really all of ``free(p); p = NULL;'' are handled
>
> Not entirely clear really....
> If I do this in the ipmitool cvs tree:
>
> find . -name '*.c' |xargs egrep free.?\\\(|wc
>
> I get:
>
> dg:speedy:ipmitool(master) => find . -name '*.c' |xargs egrep free.?\\\(|wc
> 257 518 10039
>
Dan,
I get:
253 508 9900
> So, they don't match, but it's not clear where it's missing.
>
Because not every free() case needs this patch, I guess. I went
through the sources again and it looks ok to me.
> I guess I just don't really see what the point of this patch is. Is
> there a bug somewhere where free'd memory is being accessed? If so,
> it's probably better to just try and fix that.
Yes, it's based on double-free() bug.
>
> Although these changes don't really hurt anything they do clutter
> things up quite a bit and don't have any effect in 99% of the cases.
>
I really don't see what the problem of setting pointer to NULL once it
has been freed is. It rather seems as a good practice to me. I'm not
sure about "cluttering" things either.
> Memory leaks on the other hand... Those should be addressed.
Despite I agree with you, I don't have answer.
Z.
> There
> are tons in ipmi_ekanalyzer(). I fixed most of them, but broke some
> other stuff in the process and haven't had time to go back and fix it.
>
> thanks
> dan
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Ipmitool-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
