Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 77729 invoked by uid 500); 11 May 2002 07:10:31 -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 77710 invoked from network); 11 May 2002 07:10:30 -0000 Message-ID: <3CDCC3EF.1040407@xbc.nu> Date: Sat, 11 May 2002 09:10:39 +0200 From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: sl, en-gb, en MIME-Version: 1.0 To: kfogel@collab.net CC: Justin Erenkrantz , dev@apr.apache.org Subject: Re: Removing APR_STATUS_IS_SUCCESS macro References: <20020510131655.F24386@apache.org> <85bsbn7m7w.fsf@newton.ch.collab.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Karl Fogel wrote: >Justin Erenkrantz writes: > > >>Due to some recent confusion with SVN and APR_STATUS_IS_SUCCESS, >>I'd like to consider removing this macro and just forcing >>everyone to do either a non-zero check or checking against the >>APR_SUCCESS value (which isn't strictly needed because APR_SUCCESS >>will always be 0, but that's fine with me). >> >>Thoughts? I know most of our code in APR and httpd-2.0 is >>pretty good about not using APR_STATUS_IS_SUCCESS. -- justin >> >> > >+1 if they always mean the same thing, but I'd like to first know the >answer to this question: > >If APR_SUCCESS is absolutely and always defined to be zero, then why >does apr_errno.h define the APR_STATUS_IS_SUCCESS() macro like this >under WIN32 > > #define APR_STATUS_IS_SUCCESS(s) ((s) == APR_SUCCESS \ > || (s) == APR_OS_START_SYSERR + ERROR_SUCCESS) > >and like this under OS2: > > #define APR_STATUS_IS_SUCCESS(s) ((s) == APR_SUCCESS \ > || (s) == APR_OS_START_SYSERR + NO_ERROR) > > >That looks a bit more complex than just "== 0" to me... ? > ERROR_SUCCESS and NO_ERROR are always 0. If you look at the APR_TO_OS_ERROR and APR_FROM_OS_ERROR marcos, you'll see that they _always_ get mapped to/from APR_SUCCES. So these extra checks are actually bogus, evil, and non-tax-deductible. (And the APR_FROM/TO_OS_ERROR macros are wrong, too; they should read: #define APR_FROM_OS_ERROR(e) ((e) == ERROR_SUCCESS ? APR_SUCCESS : (e) + APR_OS_START_SYSERR) #define APR_TO_OS_ERROR(e) ((e) == APR_SUCCESS ? ERROR_SUCCESS : (e) - APR_OS_START_SYSERR) ) -- Brane Čibej http://www.xbc.nu/brane/