Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Thu, 12 Aug 2004 14:27:03 -0700
From: Justin Erenkrantz <justin@erenkrantz.com>
To: dev@httpd.apache.org
Subject: Re: BRIGADE_NORMALIZE is bad coding example
Message-ID: <71E36ACBABC5BBC6778F461B@mvata-64-75.cruznet.ucsc.edu>
In-Reply-To: <20040812210310.GA16499@netspace.org>
References: <20040812210310.GA16499@netspace.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--On Thursday, August 12, 2004 5:03 PM -0400 Glenn Strauss 
<gs-apache-dev@gluelogic.com> wrote:

>  BRIGADE_NORMALIZE skips the bucket after a 0-length bucket.
> In doing so, it might skip a 0-length bucket following it.  If the last

IMHO, the cleanest correct fix is to just add an else clause.  At the cost of 
more variables, you could always use d and forgo the else clause, but I think 
that'll just confuse readers of the macro even more.  We also can't accept C99 
extensions.  *shrug*

We probably never hit this odd corner case in practice though because 
core_input_filter only has one of the following: one empty bucket, one socket 
bucket, one heap bucket, or a heap and a socket bucket: two empty buckets 
won't happen due to the design.  FWIW, BRIGADE_NORMALIZE was thrown out of 
apr-util because it was really bad to begin with: hence the comment ("This is 
bad.") and the localization of it to only server/core.c.  It was never meant 
to be an example - yet, this is a minor bug more than anything serious.  -- 
justin