apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: cvs commit: apr/test testfile.c
Date Sun, 29 Dec 2002 17:58:23 GMT
At 12:40 AM 12/29/2002, rbb@apache.org wrote:

>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.

Ok... I'm baffled...

you are [or were?] one of the prime supporters of "No Argument Validation"
for API calls.  We are *not* talking about external error events here, we are 
discussing *developer errors*.  If the developer doesn't open the file for 
APR_READ and it fails the next call to apr_file_read(), you expect they 
will truly come crying at us?

Consistency in errors should focus on external errors.  Developer errors 
which don't fail for two, maybe three calls down the line require a little 
extra effort at debugging, but they usually pop right out when the developer 
steps the offending code.

>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.

If a platform truly allows read or write access without the APR_READ or
APR_WRITE flag, that could be a bug.  But that wasn't the test I removed.

If you care to introduce a test that succeeds regardless of the apr_file_open()
results, and fails if apr_file_open() and apr_file_read() succeed without the
APR_READ bit, that test I could support.  *That* would be a platform
inconsistency we need to avoid.

>-1 (none veto) to this change.

That's fine; feel free to back up your vote with the necessary refactoring to
support it.  Don't forget this change may be necessary to some unices
when we start dealing with ACLs and other inode-metadata operations
internally, which aren't based on reading or writing the data stream (fork) 
of the file.


View raw message