On 20 Mar 2001 [EMAIL PROTECTED] wrote:
> if (APR_BRIGADE_EMPTY(b)) {
> - if (ap_get_brigade(c->input_filters, b,
>AP_MODE_BLOCKING) != APR_SUCCESS ||
> + if ((retval = ap_get_brigade(c->input_filters, b,
>AP_MODE_BLOCKING)) != APR_SUCCESS ||
> APR_BRIGADE_EMPTY(b)) {
> + apr_brigade_destroy(b);
> + if (retval != APR_EOF && retval != APR_TIMEUP) {
> + ap_log_rerror(APLOG_MARK, APLOG_ERR, retval, r,
>"ap_get_brigade() failed");
> + }
> return -1;
Should apr_brigade_destroy(b) really be called if retval == APR_SUCCESS &&
APR_BRIGADE_EMPTY(b)? It seems to me at first glance that ap_get_brigade
will probably be called again on b in that case, after it's already been
"destroyed." Of course, knowing the implementation of
apr_brigade_destroy(), I know that it can get away with that, because b is
allocated from a pool and isn't touched during the destroy; all that
happens is the brigade is cleaned out and the destruction function is
deregistered from the pool. But do we really want that to happen in a
success case from ap_get_brigade()? Just checking.
--Cliff
--------------------------------------------------------------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
