Re: Memory Leaks in SSL_Library_init()
David Schwartz wrote: The function SSL_library_init() is observed to be introudcing memory leak in the application code. There is still some amount of memory leak left even after the series of cleanup calls suggested in the openssl FAQ. Your first sentence is pretty funny though. How can a function you can only call once in the lifetime of a process introduce a memory leak? DS Once you figure that out, it won't be so funny. ;) You're making assumptions about the OS that aren't always true. b.c. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
OPENSSL_NO_FP_API, OPENSSL_NO_STDIO
Can someone explain the use of these two macros? There seem to be quite a few places where they are missing. For example... crypto/cryptlib.c crypto/conf/conf.h crypto/pem/pem.h crypto/engine/eng_openssl.c crypto/bio/bss_dgram.c crypto/rand/randfile.c crypto/asn1/a_strex.c crypto/x509v3/x509v3.h crypto/pem/pem_pk8.c I don't quite understand why one is used instead of the other. b.c. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Configure flags vs. depflags, 0.9.7 vs. 0.9.8
In 0.9.7, Configure no-ocsp would set CFLAG, DEPFLAG, write the OPENSSL_NO_OCSP define to opensslconf.h, and prune ocsp from the crypto subdirs. In 0.9.8, it no longer sets CFLAG. Was this intentional? Unfortunately, it means the compile guards in crypto/x509v3/v3_ocsp.c don't work. The macro isn't defined until the config is sourced, which is too late. I'm not sure if this is a problem with v3_ocsp.c (the compile guard should be moved down), or with Configure (the compile options should be added to CFLAG). b.c. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
