I don't understand how the memory could be reused since there is no mechanism that I know of that the runtime library would or could use to track this. For a dynamically linked C runtime library the allocated memory is held in the heap that remains after the library unloads, at which time the pointer to it is lost. When the library reloads there is no way, at least that I know of, that this memory could be found again.
There may be no portable way to handle TSD cleanup, but there is no portable way to do threading at all anyway, so I'm not sure what your argument is there. I'm not arguing that any of this needs to be done in a portable way, and of course it cannot be since dynamically loadable modules (and threading) are outside the scope of the C standard. My original response was to correct your reply to Steffen in which you stated that these 36 bytes are not leaked. The fact is that they are. Perhaps it's not a serious leak, but a leak nonetheless. Regards, Steven -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz Sent: Wednesday, 16 November 2005 3:03 PM To: openssl-users@openssl.org Subject: RE: SSL_library_init - missing 36 bytes after cleanup > Dismissing leaks as one-off's is a pet peeve of mine. The notion of > one-off leaks in an executable is arguably passable, but becomes a > plain old memory leak just like any other when packaged as a library. Not if the memory is reused if the library is unloaded and reloaded. How would you handle TSD, for example? There is no *portable* way to hook the destruction of a thread. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
