This function act like destructor. It is really strange if destructor doesn't delete object, if object haven't one method. Also function end with free deallocate pointer, see OpenSSL_free. In your code you can just put new allocation or create clear function ( I think performance doesn't differ between clear and delete+new). Also I highly recommended use tools like valgrind if possible, to check any memory leaks, also use tools like PVS studio for check code (or cppcheck or all together)
Sorry for add work to you. It is really frustrating when 8 year code doesn't work, but now I think I do openssl better. On Aug 27, 2014 9:09 PM, "Florman, Bruce via RT" <[email protected]> wrote: > Hi, and sorry about getting in on this topic so late, > Is it certain that the prior behavior of the BIO_free() function was in > fact a bug? I ask because BIO_set() provides a mechanism for initializing a > pre-allocated BIO structure, but now that BIO_free() unconditionally passes > its argument to OPENSSL_free(), there is no longer a way to de-initialize a > BIO without simultaneously de-allocating it. I had used the old conditional > behavior of BIO_free() when implementing a private stack-allocated BIO (for > inserting data formatted by various OpenSSL functions into a C++ iostream), > and was dismayed to discover that our recent update to 1.0.1i caused my > 8-year-old code to suddenly start corrupting the runtime heap. > If the new behavior of BIO_free() is now set in stone, is there any chance > of adding a BIO_unset() function to the library, to allow the > de-initialization and de-allocation to be decoupled when appropriate? > Bruce Florman | Senior Software Engineer > phone & fax +1.317.715.8115 | [email protected] > > Interactive Intelligence Inc. > Deliberately Innovative > www.inin.com > > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
