On 02.07.2019 14:04, Joe Orton wrote: > 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.
Any function that allocates memory should take a pool parameter. We can't change apr_dir_read() retroactively, but we can deprecate it and I think we should. Perhaps this is the right time to note (again) that over in Subversion land, we found that functions should take _two_ pool parameters: one for allocating the returned values and one for temporary allocations. This is better than functions creating temporary subpools for temporaries, because it allows the API consumer better control over allocations. -- Brane
