apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@apache.org>
Subject Re: cvs commit: apr/test testfile.c
Date Sun, 29 Dec 2002 06:40:47 GMT

-1.

On 29 Dec 2002 wrowe@apache.org wrote:

> wrowe       2002/12/28 21:48:51
>
>   Modified:    test     testfile.c
>   Log:
>     Remove a bogus test.  All of the original architects have argued against
>     testing for bogus (invalid) combinations of bits.  This test checked a
>     POSIX behavior of requiring the caller to request read and/or write access.
>
>     On Win32 and some other platforms that support metadata access, opening
>     a file internally for no read or write access is entirely valid.  E.g. to
>     modify the meta information, especially about directories on platforms
>     that don't support opening 'directories' for read/write access, APR already
>     uses apr_file_open() to handle the file metadata access.  I see no
>     compelling reason to emulate POSIX's fail-on-no-read-or-write-request
>     behavior.

The compelling reason is consistancy, which is the whole point of APR!
Continue to use apr_file_open internally for whatever you want, but the
API that you present to the user _must_ be consistant in how it deals with
errors for ALL platforms.  That must be one of the major tenants of APR,
or the project is completely useless.

The problem with POSIX, is that there are hundreds of different versions
of POSIX, because no two POSIX implementations are 100% identical.  If
APR's functions and error conditions aren't identical, then you are just
asking the programmer to learn one more library that has it's own porting
secrets.  The whole point of APR is that programmers don't need to worry
about porting, APR did the work for them.

-1 (none veto) to this change.

Ryan



Mime
View raw message