Lucian Adrian Grijincu wrote:
apart from the versioning detail, Iain raises a valid problem (bug) in APR:apr_dir_t objects are used to iterate dir entries (and get apr_finfo_t structures with some info about each dir entry). Scenario: I have a apr_os_dir_t object from some irelevant place in my program and I want to list all the files in that directory. For this I use apr_os_dir_put as such: apr_dir_t * d = NULL; apr_os_dir_put(&d, os_dir, pool); do{ rc = apr_dir_read(&finfo, wanted, d); printf("%s\n", finfo.name); }while(APR_SUCCESS == rc); apr_os_dir_put does not initialize the apr_dir_t->entry field, but apr_dir_read does: ret = readdir64_r(thedir->dirstruct, thedir->entry, &retent); This tries to fill the thedir->entry with some valid data about a file. (ino_t, d_off, d_name, etc.). This is a real problem only if APR endorses such a scenario. I don't know if dir_cleanup should be registered to handle the cleanup of this apr_dir_t (I'm against it). I got the apr_os_dir_t from some place else, I should manage it's death manually. If I want to let APR call closedir() on this object I can register a cleanup function for it on the same pool, manually.
Yes, although even with the allocation fixed, without dirname set correctly, it will also not be able to do the apr_stat calls if they are 'wanted' in apr_dir_read.
So the 'bug' can't really be fixed without changing the interface or adding an apr_dir_set_dirname(d, dirname)
I don't think it is a very useful interface - should it be deprecated perhaps?
We have some code that uses the existing interface but it needs to include arch/unix/apr_arch_file_io.h to access the dirname member to do the fixups.
I can't see a nice way to create an apr_dir_t from a DIR* with apr 1.2 ~mc
