On 1 September 2010 14:07, dave b <db.pub.m...@gmail.com> wrote:
> What is the rational behind not checking the return value of
> apr_palloc and apr_pcalloc?

Specifically here talking about why HTTPD code doesn't check. Ie.,
core server code and modules supplied with HTTPD.

I am clarifying this because he is hitting up on me as to why mod_wsgi
doesn't do it, yet the HTTPD code itself doesn't do it and I am just
following that precedent. So suggested he ask here why there is no
practice of checking for NULL values in HTTPD code when doing
allocations against pools. :-)

Graham

> code memory/unix/apr_pools.c from apr-1.4.2
> APR_DECLARE(void *) apr_pcalloc(apr_pool_t *pool, apr_size_t size);
> APR_DECLARE(void *) apr_pcalloc(apr_pool_t *pool, apr_size_t size)
> {
>    void *mem;
>
>    if ((mem = apr_palloc(pool, size)) != NULL) {
>        memset(mem, 0, size);
>    }
>
>    return mem;
> }
>
> and
> apr_palloc can return NULL.
> So I modified the code and the testdir test failed in one place ->
>
> "    node = active->next;
>    if (size <= node_free_space(node)) {
>        list_remove(node);
>    }
>    else {
>        if ((node = allocator_alloc(pool->allocator, size)) == NULL) {
>            if (pool->abort_fn)
>                pool->abort_fn(APR_ENOMEM); /* HERE */
>
>            return NULL;
>        }
>    }
>
> When you run the testdir (test). If you change the above to be:
>
>
> .....
>        if ((node = allocator_alloc(pool->allocator, size)) == NULL) {
>            if (!   pool->abort_fn) /* note the ! added */
>                pool->abort_fn(APR_ENOMEM);
>
>            return NULL; /* you end up here */
>        }
>    }
> and you will fail one of the tests. This to me suggests that this scenario is
> possible if the pool is like that one failed test *but* pool->abort_fn is not
> true :)
> "
>
> So what is the rational behind most users of these method *not*
> checking the return code - because from what I have seen / know it is
> possible return NULL.
>
> Also see:  https://issues.apache.org/bugzilla/show_bug.cgi?id=49847
>

Reply via email to