Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of minfrin@sharp.fm designates
 72.32.122.20 as permitted sender)
Message-Id: <EFE1E1F3-EB9F-47DE-BE52-DF448B23ECF5@sharp.fm>
From: Graham Leggett <minfrin@sharp.fm>
To: dev@httpd.apache.org
In-Reply-To: <AANLkTimpj95FqAPnwxrX8trDcDiCuVvt7E49zZkAf94e@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: rational behind not checking the return value of apr_palloc and
 apr_pcalloc
Date: Wed, 1 Sep 2010 12:15:49 +0200
References: <AANLkTimpj95FqAPnwxrX8trDcDiCuVvt7E49zZkAf94e@mail.gmail.com>

On 01 Sep 2010, at 6:07 AM, dave b wrote:

> What is the rational behind not checking the return value of
> apr_palloc and apr_pcalloc?

The rationale is to not be forced to check for and handle hundreds of  
potential failure cases when you're probably doomed anyway.

The APR pools API gives you the apr_pool_abort_set() function, which  
specifies a function to call if the memory allocation fails. In the  
case of httpd, a function is registered which gracefully shuts down  
that particular server process if the allocation fails, and  
apr_palloc() is in the process guaranteed to never return NULL.

Obviously if you're not using APR from httpd, or if you're writing a  
library that depends on APR, and you haven't set an abort function,  
NULL will potentially be returned and you should check for and handle  
that case.

Regards,
Graham
--