> On Jul 30, 2018, at 3:00 PM, Marty G <martygalyean@xxxxxxxxx> wrote: > > Of course I applaud the team's memleak testing! How could my post be interpreted otherwise? I wasn't trying to single anyone out, just the general idea that any memory leak is of little concern when the implications of the leak aren't fully known if the cause of the leak isn't known, and if one knows the cause, why not deal with it as simple good practice? One time initialization that allocates an object for the lifetime of the process has justifiably not been considered a "leak". Refactoring code to enable exit-time deallocation of static allocated objects is mostly fruitless work. The only time such "leaks" come into play is process exit and library unload. My advice is to not unload the library and to accept the fact that a small fixed amount of memory might not be deallocated at exit. Typically, even "valgrind" will not report "leaks" for addresses that are still referenced, so the static allocations are not a problem. Spending valuable cycles to eliminate these is not the most productive use of our time. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
