On Tue, Jul 02, 2019 at 11:18:31AM +0100, Joe Orton wrote: > Reading the win32 code a bit more, it is not constant-memory even with > the buffer in apr_dir_t, because it can allocate from dir->pool (and > even create cleanups!) in the more_finfo() call, so I think the current > behaviour is not justifiable.
Also, since the Unix implementation calls apr_stat(), which takes a pool, I actually can't imagine there is another way around the need for a pool passed to apr_dir_read() call to guarantee constant memory.
