Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 71029 invoked by uid 500); 19 Sep 2002 15:15:46 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 70926 invoked from network); 19 Sep 2002 15:15:46 -0000 Date: Thu, 19 Sep 2002 11:15:47 -0400 (EDT) From: Ryan Bloom To: Jeff Trawick Cc: dev@apr.apache.org Subject: Re: error handling in apr_rmm_foo busted In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On 19 Sep 2002, Jeff Trawick wrote: > Looking at the problem behind PR 12616 exposes some brokenness with > error handling in apr_rmm_*(). > > Example 1: > > apr_rmm_malloc() can return apr_status_t if a lock operation fails > or an apr_rmm_off_t otherwise. > > How can the caller know which it is? The error codes will have to be clear enough so that the caller can know. This is the limitation of the design we have for error checking. However, it is the best design I have ever seen. > Example 2: > > apr_rmm_realloc() checks for a negative return code from > apr_rmm_malloc(). The return code can't be negative because of the > data type (not to mention the logic of apr_rmm_malloc()). Yeah, that just sounds like somebody wrote code for malloc/realloc, and tried convert it quickly. Ryan _______________________________________________________________________________ Ryan Bloom rbb@apache.org 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------