I'd like to see apr_stat's semantics returned to before. If the apr_stat() succeeded, then the requested data was made available.
Adding a flag to tell APR "hey, I'm cool with partial data" is the right way for an app let APR know that it can compensate for missing data. Cheers, -g On Sat, Jan 20, 2001 at 02:40:44PM -0800, Greg Stein wrote: > On Sat, Jan 20, 2001 at 04:23:24PM -0600, William A. Rowe, Jr. wrote: > >... > > If we want to be notified, I'd suggest the high bit of the wanted arg > > is passed as APR_FINFO_FAIL. When we -must- have a user, we can do > > this instead; > > > > if (((status = apr_getfileinfo(&finfo, APR_FINFO_USER | APR_FINFO_FAIL, > > db->dirf)) != APR_SUCCESS)) > > > > Pretty gosh darned straightforward. But so is the current; > > > > if (((status = apr_getfileinfo(&finfo, APR_FINFO_USER, db->dirf)) > > != APR_SUCCESS) || !(finfo.valid & APR_FINFO_USER)) > > > > Thoughts, folks? > > Reverse the logic. > > In most cases, the caller wants exactly what was asked for. *If* the caller > can deal with some items left out, then they can declare that. > > Thus, you have: > > if ((status = apr_getfileinfo(&finfo, APR_FINFO_USER, db->dirf)) > == APR_SUCCESS) > /* we know we have the info */ > > or: > > if ((status = apr_getfileinfo(&finfo, APR_FINFO_USER | APR_FINFO_FLEXIBLE, > db->dirf)) == APR_SUCCESS) > /* we have some/all of the info. look at finfo.valid */ > > When _FLEXIBLE is passed, apr_getfileinfo() will almost never fail. It would > need to be pretty drastic :-) > > In the above scheme, all of the conversions that you did will operate just > like they used to. For code that can be flexible with the values, they have > that chance. > > [ but most code can't be flexible ] > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ -- Greg Stein, http://www.lyra.org/
