Ah, makes sense. Yeah would be insane to change the malloc replacement mid-stream so an alternate to create_with_allocator is nice.
But you also bring up an important question; I argue that you should only be able to do this on a top-level pool, not on a child pool...(In other words, create_with_allocator would not take a parent pool pointer.) On May 18, 2010, at 6:01 PM, Nick Kew wrote: > On 19 May 2010, at 00:12, Chris Knight wrote: > >> 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; > > Yes of course. It would be a separate create function, > apr_pool_create_with_allocator > or something similar but less verbose, and certainly nearer > apr_pool_create_ex. > >> 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()? > > :-) > > Surely, from the parent pool! That's only a question in a top-level create. > > -- > Nick Kew
