error handling in apr_rmm_foo busted

[Jeff Trawick <tr...@attglobal.net>]

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?

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()).

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: error handling in apr_rmm_foo busted

[Ryan Bloom <rb...@ntrnet.net>]

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
-------------------------------------------------------------------------------