I waited for any others to comment but no-one did, so here's a couple of cents.
While it might make sense in a server enviroment to have such a "malloc", complete with memory pools and whatnot, it still doesn't forgive an application from checking malloc return codes and dealing with a no-memory situation. This is a bug and needs to be fixed. Other application enviroments do not have the luxury of such a solution (embedded apps). Always check return codes. Always deal with them. Never assume it worked. Then your code will be robust. -lee -----Original Message----- From: David Schwartz [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 21, 2002 11:18 PM To: [EMAIL PROTECTED] Subject: Re: [openssl.org #49] Unchecked return values On Tue, 21 May 2002 11:33:47 +0200 (METDST), Adi Stav via RT wrote: > >Hello, > >There are numerous places in OpenSSL, especially in the BN library, >where return values of calls to malloc() or calls to functions that >can fail due to malloc() are not checked. This can cause at least >crashes that I observed when running an application using OpenSSL in >low-memory situations (e.g., using ulimit -v). OpenSSL makes it easy for you to replace its malloc with your own. I strongly recommend replacing the default malloc with one that cannot fail. I've done this on many projects and it improves their resiliency in low-memory situations. When you can't get more memory from the system, you use memory from an emergency pool as you do whatever it takes to reduce your memory consumption. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
