Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 88885 invoked by uid 500); 2 Jan 2003 17:37:35 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 88864 invoked from network); 2 Jan 2003 17:37:34 -0000 Message-Id: <5.1.0.14.2.20030102112706.02035250@pop3.rowe-clan.net> X-Sender: admin%rowe-clan.net@pop3.rowe-clan.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 02 Jan 2003 11:34:50 -0600 To: Jeff Trawick From: "William A. Rowe, Jr." Subject: Re: cvs commit: apr/test testfile.c Cc: dev@apr.apache.org, In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 02 Jan 2003 17:39:34.0687 (UTC) FILETIME=[EA0C62F0:01C2B285] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 09:56 AM 1/2/2003, Jeff Trawick wrote: > writes: > >> Guys, this is ridiculus. If a test fails, the correct approach is not to >> remove the test from the test suite. The hole point of the test suite is >> to ensure that APR works the same on _ALL_ platforms. If it doesn't, then >> it is just as hard to write portable programs with APR as without. >> >> There are two options when a test fails. 1) Fix the bug in the APR code. >> 2) Introduce a feature macro that allows programmers to determine if a >> feature exists with #ifdefs. Removing a test is _not_ an option. It >> weakens APR's portability. >> >> Plus, not long after Will added this test, I posted to the list remarking >> that it was a problematic test and looking for possible solutions. We >> should at least have a conversation over how we want to deal with this. >> >> -1 for removing this test. > >What is the precise technical reason for your veto? > >I think it is not a valid property to test in an APR test suite >(outside the scope of APR) and it is harmful to leave it there (not >portable). In this case, I agree with Jeff's commit. I also disagree that you can veto a veto (which I consider Jeff's reversion of this test to be.) It was introduced as a pedantic test to try to illustrate to you, Ryan, the futility of making all platforms behave *identically*. That isn't reasonable or feasible without adding a ton of extra cycles. Apparently this mental exercise didn't have the effects I had hoped. Jeff's patch is correct; it isn't APR's job to determine if one can 'open' a directory as a file. Opening a directory as a file isn't portable, no, but we can't "help" the programmer on every possible portability issue. When the offending code is moved to Win32, yes that will fail. And then the porter will need to troubleshoot their code, see that they are trying to 'open' all files *and* sub-directories, and they will have to modify their code. That's the breaks, we have to draw some line between enabling portability and enforcing portability. That line is somewhere about the point that APR stops performing adequately. Bill