Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 42741 invoked by uid 500); 13 Oct 2002 23:39:22 -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 42730 invoked from network); 13 Oct 2002 23:39:22 -0000 Date: Sun, 13 Oct 2002 19:39:28 -0400 (EDT) From: rbb@apache.org X-Sender: rbb@shell.ntrnet.net To: Aaron Bannert Cc: dev@apr.apache.org Subject: Re: apr_ipsubnet_test In-Reply-To: <20021013232605.GI4179@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 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_*. Ryan _______________________________________________________________________________ Ryan Bloom rbb@apache.org 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------