Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Sender: trawick@rdu26-58-158.nc.rr.com
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Cc: <dev@apr.apache.org>
Subject: Re: APR_INCOMPLETE confusion
References: <m3zo9htji2.fsf@rdu26-58-158.nc.rr.com>
	<1d9801c11c32$48ef0110$93c0b0d0@roweclan.net>
From: Jeff Trawick <trawick@attglobal.net>
Date: 03 Aug 2001 13:25:12 -0400
In-Reply-To: <1d9801c11c32$48ef0110$93c0b0d0@roweclan.net>
Message-ID: <m3zo9hqcnb.fsf@rdu26-58-158.nc.rr.com>
Lines: 46
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"William A. Rowe, Jr." <wrowe@rowe-clan.net> writes:

> From: "Jeff Trawick" <trawick@attglobal.net>
> Sent: Friday, August 03, 2001 7:28 AM
> 
> 
> > I'm happy to create a new APR_INCOMPLETE_CHAR status, hijack the
> > current doc for APR_INCOMPLETE, and change Apache/APR as appropriate.
> > 
> > Does APR_INCOMPLETE (for incomplete file status) need to be renamed as
> > well for clarity?  APR_INCOMPLETE_STATUS may be sufficiently clear.
> > 
> > Comments?
> 
> the list seems to have an issue with the proliferation of error result codes.  
> I don't have a set opinion on this, and certainly a few more will be warrented 
> over time.

maybe the description of APR_INCOMPLETE should be made more vague
(slightly less useful to somebody trying to see what it means) to
cover different uses?

but programmers are one thing, and they can grep the source code if
they're confused; end users are yet another, and there is no easy
workaround for a vague error string from apr_strerror()

> The flavors I can see are;
> 
> APR_SUCCESS   processed all input, provided all expected output
> 
> APR_???       processed all input, can only provide some expected output
>               (generally a system limitation, such as stat)
> 
> APR_???       processed some input, but remaining input is _invalid_
>               (as apr_xlate means, are we expecting more input?)
> 
> APR_???       processed some input, have more output but the output buffer
>               is filled (apr_xlate treats this as APR_SUCCESS, which probably 
>               isn't entirely healthy.)

it is an expected condition; nothing is wrong with the input :)

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...