One of the early hacks that was added to APR was the ability to call apr_p(c)alloc with a NULL pool. This would make apr_p(c)alloc use malloc internally to allocate the memory. I would like to remove this feature, but it has some far-reaching implications if I do, so I am checking here first.
The problem is that the support for NULL pools has always been a bit half-assed, and it is very difficult to get it right. We really need a more generalized set of memory routines that would allow people to allocate from a pool, the heap, or shared memory. I started to go through the APR code today to cleanup the NULL pool stuff, and it is non-trivial. Think about it this way, we use pools for a lot more than just allocating memory, we also use pools for cleaning up after ourselves. As things stand right now, we have some serious memory leaks in APR, because we allow people to allocate out of a NULL pool. For example: apr_open is called with a NULL pool, and the APR_BUFFERED flag, we will allocate 4k on a unix machine for the buffer, that is never freed. Even if we go through and manually free all of the allocated memory if the pool is NULL, we still have the problem that we can't register cleanups, so we are forcing people to manually destroy whatever variables they create. Can we get a quick (like within 24 hrs) decision on which direction we want to go with this. I plan to make the change quickly, either cleaning up the memory leaks by manually freeing them, or removing the NULL pool hack. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
