apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: APR_INCOMPLETE confusion
Date Fri, 03 Aug 2001 17:48:55 GMT
From: "Jeff Trawick" <trawick@attglobal.net>
Sent: Friday, August 03, 2001 12:25 PM


> "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 :)

All these incompletes are 'expected conditions', that doesn't mean they don't
get an apr_status_t _status_ result (as opposed to an error result).  For example,
where APR_OOPS means our buffer filled, and APR_UGH means we are still looking...

eg 

    do {
        load up the inbuf (may not be entirely empty)

        while ((rv = apr_xlate_thing(inbuf, outbuf)) == APR_OOOPS) {
            /* empty the outbuf and continue */
            if (cant_empty)
                break;
        }

    } while (more_input && (rv == APR_SUCCESS || rv == APR_UGH))

    if (rv)
        emit_error(rv);

gives us many possibilities...

rv == APR_OOOPS - "Insufficient Buffer" (forgot to check?)
rv == APR_UGH   - "Invalid trailing character" (forgot more input?)
rv == APR_other - something's broken

rv == APR_SUCCESS - no error :)

Bill



Mime
View raw message