On 02.07.2019 08:49, Joe Orton wrote: > On Thu, Jun 27, 2019 at 05:01:56PM +0300, Ivan Zhakov wrote: >> On Tue, 25 Jun 2019 at 17:21, <jor...@apache.org> wrote: >> >>> Author: jorton >>> Date: Tue Jun 25 14:21:56 2019 >>> New Revision: 1862071 >>> >>> URL: http://svn.apache.org/viewvc?rev=1862071&view=rev >>> Log: >>> Add apr_dir_pread(), a variant of apr_dir_read() which allows callers >>> to read a directory with constant memory consumption: > ... >> I'm not sure it's best fix. Better solution would be allocate buffer for >> dirname + MAX_FILE_NAME in apr_dir_t and reuse it on every iteration. Win32 >> already has such code. > I didn't look at win32 too closely, so on win32 currently doing: > > apr_dir_open(&x, ...); > apr_dir_read(&f1, ..., x); > apr_dir_read(&f2, ..., x); > > invalidates f1? That's pretty ugly, there is no indication in the API > that apr_dir_read() has side-effects like that.
The 2.0 docstring says explicitly that "memory is allocated in the pool passed to apr_dir_open()". While this is really bad API design (hence apr_dir_pread() ...), it pretty much forbids the implementation from reusing an internal name buffer. Looks like the Windows implementation needs fixing? -- Brane
