"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> > 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...
okay, okay, you're right of course :)
The simple fact is that I barely have time now to try to make truly
broken stuff work properly; I thought I would try to spend minimial
time and lessen the confusion between the different uses of
APR_INCOMPLETE; apparently there is no palatable quick fix.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
