Well! I tend to disagree here.. Any resource should be freed immediately if it is not in use.. function does not know how all the variables on heap be handled outside of the function, if those are not dealt internally unless returned in all cases to the function caller.. Besides, static analysis of the code is reporting resource leak at this code block and it should be fixed for the same reason and will be more clearer for callers of this function. Freeing resource immediately once it is not in use is normal practice and must be followed in all cases as how I see it :) Do you know when is 'ptr' get free'd and at which point in code? sorry i m not very familiar with all iptables codebase, so if you can guide me I can sure come up with proper fix for it.. thanks ________________________________________ From: Jan Engelhardt [jengelh@xxxxxxx] Sent: 07 September 2015 16:08 To: Zaman, Imran Cc: netfilter-devel@xxxxxxxxxxxxxxx Subject: RE: [PATCH v1 1/1] fix: resource leakage when loading library using dlopen On Monday 2015-09-07 12:52, Zaman, Imran wrote: >Aah. ookey.. so it needs to be moved two lines below.. At which point it's almost useless, because the program will end if the requested extension cannot be loaded. >What about the caller of the function? is it getting closed at any stage? Implicitly at program exit. It's not pretty valgrind-wise, but implicit resource freeing seems a not-uncommon practice for some programs. --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
