From: SourceForge.net <no...@so...> - 2011-08-09 06:00:08
|
Patches item #3383970, was opened at 2011-08-01 15:32 Message generated for change (Comment added) made by yaberauneya You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3383970&group_id=12694 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Garrett Cooper (yaberauneya) Assigned to: Nobody/Anonymous (nobody) Summary: Fix compile error on FreeBSD 9.x/POSIXify auto_nlist, etc Initial Comment: 1. The n_name field was const-ified in FreeBSD 9.x recently, so temporary memory needs to be created to manipulate the kernel symbol name referenced in auto_nlist, et all. 2. The arguments being passed to auto_nlist, et all aren't correct per the POSIX spec (signedness is wrong and the prototype isn't using generic, i.e. void* pointers). The solution for 1. is a bit hacky and seems like it would leak memory, but I could be wrong... the 1. solution definitely needs a second pair of eyes to ensure that it's solving things appropriately. ---------------------------------------------------------------------- >Comment By: Garrett Cooper (yaberauneya) Date: 2011-08-08 23:00 Message: This new patch still leaks memory, so it's not perfect; it also introduces a potential thread safety issue if the API is called from multiple threads simultaneously. That said, the attached patch doesn't grow without bound. The next best thing after this could be to initialize the memory/structure outside of the function, grab the result, and free the memory/structure. ---------------------------------------------------------------------- Comment By: Garrett Cooper (yaberauneya) Date: 2011-08-03 13:18 Message: Here's a more complete fix of the attached patch: https://gitorious.org/net-snmp-bsd/net-snmp-bsd/commit/c96fa591d652bf0477183f16452a8150b6f5a62a Let me see if I can dig up more details about what can be done to workaround this const-ification issue. ---------------------------------------------------------------------- Comment By: Wes Hardaker (hardaker) Date: 2011-08-03 10:44 Message: The first part of the patch will definitely leak memory. The problem is that no solution is ideal: 1) if the item truly should be const (ie, it's a static assignment from somewhere else that shouldn't be modified) then we should copy it into a local copy of the structure, discard the const and modify it. 2) assume that it's not a copy that can't be modified and simply discard the const. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3383970&group_id=12694 |