> On Mar 15, 2016, at 3:28 PM, Graham Leggett <minf...@sharp.fm> wrote: > > The trouble with the above is that because of the pool cleanup we now have, > pfds[3] needs to live as long as pool p. In your example it does, but there > is nothing stopping someone trying to allocate pfds[3] on the stack and then > returning. Later the cleanup is run, and boom - difficult to debug crash or > weird behaviour. > > With the array you’re guaranteed the memory is allocated from a pool, which > means the pool cleanup will always be safe. > > What we should also do is drop the apr_pool_t *p parameter and read it from > apr_header_array_t’s pool instead. This will be a further check to stop the > caller from doing anything pathological, as we definitely know the cleanup > and the array belong to each other, and our API becomes simpler still. > > Attached patch does this. >
+1
