On Tue, Mar 15, 2016 at 8: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.
Was just an example on the possibily to use a plain array for the interface (a stacked one is of course not recommended to register an event callback likely run out of scope). > > With the array you’re guaranteed the memory is allocated from a pool, which > means the pool cleanup will always be safe. You convinced me, I like your may better now ;) Possibly we could also force each pfd->p to pfds->pool in event_register_poll_callback_ex(). > > 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 Regards, Yann.
