Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-Id: <5.1.0.14.2.20021013185652.03643b48@pop3.rowe-clan.net>
Date: Sun, 13 Oct 2002 18:57:33 -0500
To: rbb@apache.org
From: "William A. Rowe, Jr." <wrowe@apache.org>
Subject: Re: apr_ipsubnet_test
Cc: Aaron Bannert <aaron@clove.org>,dev@apr.apache.org
In-Reply-To: <Pine.LNX.4.21.0210131936530.24390-100000@shell.ntrnet.net>
References: <20021013232605.GI4179@clove.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:39 PM 10/13/2002, rbb@apache.org wrote:
>On Sun, 13 Oct 2002, Aaron Bannert wrote:
>
>> On Sun, Oct 13, 2002 at 11:53:27AM -0400, Ryan Bloom wrote:
>> > > Is there a more APR-ish way to describe returning "true" or "false"
>> > > than
>> > 
>> > As with all other APR functions.  APR_SUCCESS indicates "true", Some other
>> > APR_STATUS code indicates false.
>> 
>> No it doesn't. True and false can be orthogonal to success/failure.
>> How does one express a successfully false condition?
>
>that is why it is apr_status_t, not apr_error_t.  There are specifically a
>set of status codes that do not indicate errors, only status
>conditions.  That series of values starts with APR_OS_START_STATUS, and
>examples of them are APR_INCHILD, APR_INPARENT, APR_DETACH.  They are
>commonly identified by the fact that they aren't APR_E*, rather they are
>just APR_*.

Shouldn't these consistently return true for APR_STATUS_IS_SUCCESS()?
Seems like a good argument for retaining that macro we debated before.