apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: svn commit: r1862071 - in /apr/apr/trunk: file_io/os2/dir.c file_io/unix/dir.c file_io/win32/dir.c include/apr_file_info.h test/testdir.c
Date Tue, 02 Jul 2019 06:49:38 GMT
On Thu, Jun 27, 2019 at 05:01:56PM +0300, Ivan Zhakov wrote:
> On Tue, 25 Jun 2019 at 17:21, <jorton@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.



Mime
View raw message