On ons, 2008-02-27 at 09:05 +0100, Magnus Fromreide wrote: > I have attached a first version of destruct and clone for > netsnmp_mib_handlers in order to demonstrate the concept. > > I would really like to get comments on it. > > The patch do incidentally fix a memory leak in the agent, and there are > more similar low hanging fruit available.
Now I have looked further. It seems as if the only places that tries to duplicate netsnmp_mib_handler's inside of our tree are the injectHandler handling and the range registration support. The injectHandler case is worked around by the simple act of noticing that none of the injectHandler handlers have any myvoid-data so the myvoid field is simply not copied. Thus the only remaining problem site is the handling of rage registrations. Now, as I see it the problem stems from the fact that the various structures try to do to much. An netsnmp_mib_handler have the fields handler_name, myvoid(possibly), flags(partially), and access_method that describe what it is to do. These could just as well be shared between all instances of the handler and they could also be constant. The netsnmp_mib_handler also have the fields myvoid(possibly), flags(partially), next and prev that describe how it should be handled for a certain instance, these are the fields that force the duplication of the handler for each instance. The struct could of course not be split since that would brek backwards compatibility. /MF ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
