On Fri, Jun 08, 2001 at 12:48:40PM -0400, Cliff Woolley wrote:
>...
> range-end where necessary. So in theory, these particular calls to
> apr_brigade_partition() should never fail, unless something really
> catastrophic happens between the calls to apr_brigade_length() and
> apr_brigade_partition(). That's why it worked fine before to just ignore
> the possibility of a NULL return from apr_brigade_partition()... it just
> shouldn't ever happen.
It can definitely happen.
Consider a brigade that contains a PIPE bucket from a CGI. When we go to
partition it, we read from the PIPE. Are you *sure* that read will never
return an error on us? :-)
> If we do want to explicitly handle errors here, I think the way to do it
> is to move the calls to apr_brigade_partition() above the block that adds
> the range specifiers to the output stream and simply "continue;" if one
> of the calls fails for some wacky reason.
Sure. We should also log an error because it means that something has broke
down during a bucket read. A failing CGI, for example.
> I'm tempted to just keep on ignoring the [slim] possibility of an error in
> this case and to simply add a comment explaining these assumptions.
> Maybe an AP_DEBUG_ASSERT() on the return values to add future-proofness?
Definitely not an AP_DEBUG_ASSERT. Then we would never see anything out in
the real world. It will just mysteriously die.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
