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

[Branko Čibej <br...@xbc.nu>]

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.

My proposed patch for the ENOENT issue would then be:

Index: apr_errno.h
===================================================================
RCS file: /home/cvs/apr/include/apr_errno.h,v
retrieving revision 1.91
diff -u -r1.91 apr_errno.h
--- apr_errno.h 20 May 2002 13:22:36 -0000      1.91
+++ apr_errno.h 28 Jun 2002 19:40:58 -0000
@@ -923,6 +923,7 @@
                 || (s) == APR_OS_START_SYSERR + WSAENAMETOOLONG)
 #define APR_STATUS_IS_ENOENT(s)         ((s) == APR_ENOENT \
                 || (s) == APR_OS_START_SYSERR + ERROR_FILE_NOT_FOUND \
+                || (s) == APR_OS_START_SYSERR + ERROR_PATH_NOT_FOUND \
                 || (s) == APR_OS_START_SYSERR + ERROR_OPEN_FAILED \
                 || (s) == APR_OS_START_SYSERR + ERROR_NO_MORE_FILES)
 #define APR_STATUS_IS_ENOTDIR(s)        ((s) == APR_ENOTDIR \



Wrowe and I discussed this quite a bit, but haven't come to a final 
decision yet. I'm bringing it up again because this is definitely 
something that has to be fixed before we hit 1.0.

    Thanks,

-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/

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

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