Thanks, I mostly didn't want it to be part of apr_pool_create because then you'd have to change every instance of calling apr_pool_create; plus most users will not need this capability so rather not have 99% of apr_pool_create calls with 3 NULL's at the end. Also the semantics get a little confusing in doing this at apr_pool_create; is the apr_pool_t * allocated from the allocator_alloc_fn or via malloc()?
On May 18, 2010, at 3:58 PM, Nick Kew wrote: > Aaargh, just accidentally sent this to Chris instead of list. > /me grumbles about missing Reply-To headers. > >> On 18 May 2010, at 23:14, Chris Knight wrote: >> >>> +/** >>> + * Redefines the function used by this apr_allocator to allocate a block >>> of memory. >>> + * @param allocator The allocator to set the memory allocation functions on >>> + * @param alloc_fn The function for me to call when apr_allocator_alloc is >>> called >>> + * @param free_fn The function for me to call when apr_allocator_free is >>> called >>> + * @param opaque The opaque information to pass to these back-end functions >>> + */ >>> +typedef apr_memnode_t *(apr_allocator_alloc_fn_t)(apr_size_t size, void >>> *opaque); >>> +typedef void(apr_allocator_free_fn_t)(apr_memnode_t *memnode, void >>> *opaque); >>> +APR_DECLARE(apr_status_t) apr_allocator_set_fns(apr_allocator_t >>> *allocator, apr_allocator_alloc_fn_t *alloc_fn, apr_allocator_free_fn_t >>> *free_fn, void *opaque); >> >> Nice little generalisation! >> >> At what point do you call apr_allocator_set_fns? I'd guess just after the >> pool >> has been created, right? Any reason not to integrate it into pool creation >> by passing it optional allocator fns? >> >> -- >> Nick Kew >
