Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [VOTE] httpd-2.2.20 tarballs
Date: Wed, 31 Aug 2011 10:41:38 +0200
Message-ID: 
 <E563FB5AB3F02844AC749BA39E494AB4053BC06E@VF-MBX11.internal.vodafone.com>
In-Reply-To: <4E5D20F3.2090809@rowe-clan.net>
Thread-Topic: [VOTE] httpd-2.2.20 tarballs
Thread-Index: AcxnPDV/IM4LqQYbTryhbyYCPoIjnwAfUhZQ
References: 
 <E563FB5AB3F02844AC749BA39E494AB4040CA35F@VF-MBX11.internal.vodafone.com>
 <73CCF316-B818-4904-AC80-BB3B24607BF1@jaguNET.com>
 <A19DACA0-EF49-402F-8B2E-D6412ED7E6C7@jaguNET.com>
 <4E5D1454.30704@rowe-clan.net>
 <CAHSOX_A=KG2q_roD=Lq5Ecd49hDaQ8W5z51Pj60H4fcwUFWiuw@mail.gmail.com>
 <4E5D20F3.2090809@rowe-clan.net>
From: =?iso-8859-1?Q?=22Pl=FCm=2C_R=FCdiger=2C_VF-Group=22?=
 <ruediger.pluem@vodafone.com>
To: <dev@httpd.apache.org>

=20

> -----Original Message-----
> From: William A. Rowe Jr. [mailto:wrowe@rowe-clan.net]=20
> Sent: Dienstag, 30. August 2011 19:42
> To: dev@httpd.apache.org
> Subject: Re: [VOTE] httpd-2.2.20 tarballs
>=20
> On 8/30/2011 12:34 PM, Greg Ames wrote:
> >=20
> >=20
> > On Tue, Aug 30, 2011 at 12:48 PM, William A. Rowe Jr.=20
> <wrowe@rowe-clan.net
> > <mailto:wrowe@rowe-clan.net>> wrote:
> >=20
> >     On 8/30/2011 10:18 AM, Jim Jagielski wrote:
> >     > If we get enough votes by, say, 1:30pm Eastern time=20
> (2hrs), I'll retag
> >     > and reroll... Otherwise, I'll go ahead w/ releasing 2.2.20.
> >     >
> >     > PS: Power and net are bouncing like jumping beans so=20
> I'll check
> >     >     when I can :)
> >=20
> >     It seems this could actually break resume requests for=20
> .iso images,
> >     for example, so it seems prudent to reroll.
> >=20
> >=20
> > can you elaborate on how this could cause breakage please? =20
> we have to retest if we reroll.
>=20
> Nevermind, the commit is a noop, any bug still exists, we=20
> should just continue
> with this package.  If the brigade must be split at 5Gb, it=20
> will fail with or
> without this patch.

It will not fail, as we know that the parameter we pass to =
apr_bucket_split
is within the limits of apr_size_t due to earlier checks in apr_uint64_t =
arithmetic.
It is really just silencing a compiler warning.

Regards

R=FCdiger