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
On Wed, Sep 1, 2010 at 6:15 AM, Graham Leggett minf...@sharp.fm wrote:
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
On 1 September 2010 20:15, Graham Leggett minf...@sharp.fm wrote:
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
On Wed, Sep 1, 2010 at 6:37 AM, Graham Dumpleton graham.dumple...@gmail.com
wrote:
On 1 September 2010 20:15, Graham Leggett minf...@sharp.fm wrote:
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
On 1 September 2010 22:08, Jeff Trawick traw...@gmail.com wrote:
On Wed, Sep 1, 2010 at 6:37 AM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
On 1 September 2010 20:15, Graham Leggett minf...@sharp.fm wrote:
On 01 Sep 2010, at 6:07 AM, dave b wrote:
What is the rational behind not
On Wed, Sep 1, 2010 at 2:49 PM, dave b db.pub.m...@gmail.com wrote:
On 1 September 2010 22:08, Jeff Trawick traw...@gmail.com wrote:
On Wed, Sep 1, 2010 at 6:37 AM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
On 1 September 2010 20:15, Graham Leggett minf...@sharp.fm wrote:
On
My 2 cents:
I doubt that any of the core devs are going to match you for devotion to
this topic, but I'm sure we will review patches to trunk to fix somewhat
practical scenarios, such as ensuring that memory allocation failures during
request processing go through the common abort function,
On Wed, Sep 1, 2010 at 4:09 PM, dave b db.pub.m...@gmail.com wrote:
My 2 cents:
I doubt that any of the core devs are going to match you for devotion to
this topic, but I'm sure we will review patches to trunk to fix somewhat
practical scenarios, such as ensuring that memory
no, I don't want you to do anything for me; I'm just sharing my educated
guess at what it takes to make progress on this topic you're apparently very
interested in
with a little luck you'll be able to find somebody here to analyze the code
you pointed out to see which cases actually matter,
On 9/1/2010 10:17 PM, dave b wrote:
Why not just fix it now and not worry? ...
It will help if you can provide a specific use case for graceful failure.
A segfault/dereference of NULL pointer provides a very specific exception
for this general case, and 'recovers' neatly from a process which
10 matches
Mail list logo
