apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lucian Adrian Grijincu" <lucian.griji...@gmail.com>
Subject Re: apr_os_dir_put fixes
Date Tue, 11 Dec 2007 15:42:48 GMT
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).

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);
			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.

On Dec 11, 2007 3:44 PM, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> Iain Wade wrote:
> >
> > It has the drawback of altering the apr_os_dir_put() function to
> > accept an extra argument (dirname). I don't know your policy of stable
> > interfaces, but I haven't really been able to find any other users of
> > this call in my searching.
> Irrelevant, our versioning policy is really clear (and becoming more
> pedantic <shrug/>).
> http://apr.apache.org/versioning.html
> If you look, you'll find some _ex() flavor functions.  These are the
> byproduct that we can add a new facility to 1.3.0 (which is still in
> development) and cannot modify an existing one.
> _ex() flavors tend to go poof when the original is marked @deprecated
> and the new _ex() flavor becomes the 'normal' flavor in 2.0.0, which
> is some ways off.


View raw message