Re: APR_STATUS_* semantics [Re: Breaking something? Now is the time?]

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 02:43 PM 6/28/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>Since we're talking about semantics, breakage, etc, I'll take the 
>opportunity to bore everybody with an issue I'd like resolved, too; 
>Namely, the semantics of the APR_STATUS_IS_* macros.
>
>I've said several times before that APR_STATUS_IS_ENOENT and 
>APR_STATUS_IS_ENOTDIR don't have the same meaning on Windows and Unix. 
>That's because Windows doesn't have an error code that would mean exactly 
>the same as the Posix ENOTDIR. Simulating it would be a huge cost, though.
>
>Here's an example of the differing behaviour: If "foo" does not exist, 
>doint an apr_stat("foo/bar") will trigger APR_STATUS_IS_ENOENT on Unix, 
>but APR_STATUS_IS_ENOTDIR on Windows. That makes it very hard to write a 
>porable "mkdir -p" implementation; and, indeed, apr_dir_make_recursive 
>can't work correctly on Windows because of that.
>
>What I'd like to propose is that we document that, for any given status 
>code, _more_ than one APR_STATUS_IS* macro can match, and it's the 
>programmer's responsibility to decide in what order to make the tests.

Brane, thank you for a terrific explanation of the issue.  +1 here.

Bill

Re: APR_STATUS_* semantics [Re: Breaking something? Now is the time?]

[Cliff Woolley <jw...@virginia.edu>]

On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:

> >What I'd like to propose is that we document that, for any given status
> >code, _more_ than one APR_STATUS_IS* macro can match, and it's the
> >programmer's responsibility to decide in what order to make the tests.

+1

--Cliff