On 07/30/2018 02:34 PM, Salz, Rich via openssl-users wrote:
* So why not just have a rule "don't litter"
Have you looked at, say, the memleak testing we do?
Thanks for the two cents.
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?
But nothing beats good programming habits for cleaning up, i.e. "not
littering" in the first place, as after the fact testing doesn't
necessarily catch all cases where leaks can occur. Analogous care at
the programming stage applies to buffer overruns also as catching them
after the fact is a dynamic trap shoot. Same philosophy though. As
previously noted by another in this thread, the memleak may be load or
data size dependent. Or it may be dependent on some intermittent state
of the underlying OS. Some leaks can occur from structures accessed
only via handles to the process and the OS doesn't necessarily release
those structures when a process exits. But if the dev *always*
explicitly makes the call to the system to release those structures via
the handle then one can be far less concerned about the implications
about what the system will or won't do if one doesn't
For what it is worth, from my view, I'm addressing a small percentage of
developers out there who may have not considered the implications of
some of this and how easy it can be avoided altogether with some simple
practices at code time, rather than trying to mop up later in dynamic
testing. I have nothing but the highest respect and gratefulness for
the sweat and care behind openssl and wouldn't be posting at all if I
didn't, so thank you!
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
