Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 48806 invoked by uid 500); 2 Jul 2002 21:02:56 -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 48793 invoked from network); 2 Jul 2002 21:02:55 -0000 Date: Tue, 2 Jul 2002 16:59:48 -0400 (EDT) From: Cliff Woolley X-X-Sender: root@bistromath.cs.virginia.edu To: Aaron Bannert cc: kfogel@collab.net, , Subject: Re: proposal to add apr_check_dir_empty() to APR In-Reply-To: <20020702135909.R1936@clove.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tue, 2 Jul 2002, Aaron Bannert wrote: > Non-APR functions that want to use APR's apr_status_t codes don't have > the luxury of being able to add another code, so given the performance > tradeoff maybe this is the way to go... Well, they *can*, but APR doesn't know what to do with them. That's not a problem in general -- apr-util does it for example. The part that strikes me as silly is having this massive explosion of status codes when all we're trying to return is "true" or "false". Why not just provide for that in APR, leaving 3rd party status codes for things that REALLY need them (actual unusual conditions, errors, statuses, whatever). Why make people add their own "APR_FALSE"? --Cliff