You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ji...@apache.org on 2007/10/29 21:56:26 UTC
svn commit: r589854 - /httpd/httpd/branches/2.2.x/STATUS
Author: jim
Date: Mon Oct 29 13:56:25 2007
New Revision: 589854
URL: http://svn.apache.org/viewvc?rev=589854&view=rev
Log:
Note rationale :)
Modified:
httpd/httpd/branches/2.2.x/STATUS
Modified: httpd/httpd/branches/2.2.x/STATUS
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=589854&r1=589853&r2=589854&view=diff
==============================================================================
--- httpd/httpd/branches/2.2.x/STATUS (original)
+++ httpd/httpd/branches/2.2.x/STATUS Mon Oct 29 13:56:25 2007
@@ -226,6 +226,17 @@
niq: Doesn't allocating 2^n+1 bytes risk being horribly inefficient?
Would it make sense to reduce AP_IOBUFSIZE to 8091 so buf doesn't
go one over a big boundary?
+ jim: The issue is that we allocate an array of AP_IOBUFSIZE
+ but go beyond that (note we send the end to curpos+AP_IOBUFSIZE)
+ so it's not just reducing AP_IOBUFSIZE since then we would
+ hit the bug at 8191 boundary instead of the 8192 one.
+ The actual PR suggests simply removing the setting of '\0'
+ which looks good, but there are loads of places in the related
+ code where we use AP_IOBUFSIZE, so it seemed safer to me to
+ simply allocate an extra byte. Note that other sections of
+ code do this by setting the endpos to one less to "save"
+ space for the NUL, but they don't have related sections
+ which assume a set size; this does (AP_IOBUFSIZE).
PATCHES/ISSUES THAT ARE STALLED
Re: /httpd/httpd/branches/2.2.x/STATUS
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Oct 29, 2007, at 5:44 PM, Nick Kew wrote:
>
> * The second is more complex. Because of the order of changes
> to trunk, it needs the first as prerequisite. To make a separate
> change for it would necessarily invalidate the other patch.
>
> There are far too many interlinked combinations here to deal with
> individually. So if the veto stands, I think I'll just have to
> replace both proposals with a combined patch for both bugs.
> Unless someone has a better idea?
>
I think that a combined patch that addresses both "bugs" makes the
most sense... I can't see approving one and not the other, due
to the effects on existing users :)
Re: /httpd/httpd/branches/2.2.x/STATUS
Posted by Nick Kew <ni...@webthing.com>.
On Mon, 29 Oct 2007 20:56:26 -0000
jim@apache.org wrote:
> httpd/httpd/branches/2.2.x/STATUS Mon Oct 29 13:56:25 2007 @@ -226,6
> +226,17 @@ niq: Doesn't allocating 2^n+1 bytes risk being horribly
> inefficient? Would it make sense to reduce AP_IOBUFSIZE to 8091 so
> buf doesn't go one over a big boundary?
> + jim: The issue is that [chop]
Jim, that's not what I was asking. But anyway, given that the "big"
boundary is 8192 not 8092, my question is moot.
Today have another discussion that would be better aired on-list
than in STATUS: PR42592 and PR41798:
* The first is small and simple, but went through a couple of
iterations. AIUI you're now objecting based on a comment
that was right for r583002, partially invalidated but not
updated in r583803, but only properly fixed in r588791.
That seems to me a tenuous reason for a veto, given that
there is also a proposal to backport r588791.
* The second is more complex. Because of the order of changes
to trunk, it needs the first as prerequisite. To make a separate
change for it would necessarily invalidate the other patch.
There are far too many interlinked combinations here to deal with
individually. So if the veto stands, I think I'll just have to
replace both proposals with a combined patch for both bugs.
Unless someone has a better idea?
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/