Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Sat, 11 Nov 2000 20:30:22 -0800 (PST)
From: rbb@covalent.net
To: new-httpd@apache.org, cliffwoolley@yahoo.com
Subject: Re: Implementing split() on pipe buckets?
In-Reply-To: <20001112042243.23304.qmail@web3201.mail.yahoo.com>
Message-ID: <Pine.LNX.4.21.0011112029010.24741-100000@koj.rkbloom.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


> One other point about this: all of the rest of the bucket code checks for failed
> mallocs.  Consistency is a Good Thing.  Besides, if there's some weird (but
> recoverable) reason that malloc might fail on some quirky platforms (hypothetical
> situation), then it seems that the Right thing to do would be to return the correct
> apr_status_t value (APR_ENOMEM), rather than returning APR_SUCCESS if the function
> really didn't succeed.  Note that a failure of malloc here might not turn up until
> much later, and debugging it could be a huge hassle.  Of course, in normal
> situations, malloc shouldn't fail unless you're flat out of memory, but why trust it
> (and why bother having the APR_ENOMEM return code in the first place)?

I also agree that consistency is a good thing.  Having the buckets return
ENONMEM is wrong in all places.  APR provides that error code for programs
other than Apache.  Apache in general just doesn't use ENOMEM.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------