apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: New apr_stat/apr_dir_read behavior
Date Mon, 12 Dec 2005 20:29:44 GMT
On 12/12/05, Julian Foad <julianfoad@btopenworld.com> wrote:

> Presumably the APR developers have decided that this error code will now have a
> wider meaning than is documented.

See, that's the thing, I'm not sure how this is happening.  The code
in question doesn't seem to have changed in any meaningful way in
quite some time.

> Should functions be allowed to return that status without saying so in their
> doc strings?  I wonder if there's much point in returning it unless callers
> know officially that it is possible.
> When apr_stat() returns APR_INCOMPLETE, presumably finfo->valid tells which
> fields are valid.  This ought to be documented.

Agreed, I will look into making that change in APR.

> When apr_dir_read() returns APR_INCOMPLETE, from an API user's point of view it
> could mean the list of directory entries is incomplete and/or 'finfo' is
> incomplete.  How is the user supposed to know?  This needs to be documented.
> Please could some APR person deal with the above points?

Will do.

> A side-note for Subversion:
> Subversion's existing test for APR_INCOMPLETE should be converted to
> APR_STATUS_IS_INCOMPLETE.  (There is just one, I think: in svn_io_copy_file().)

Yes, it should use APR_STATUS_IS_INCOMPLETE.


View raw message