httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j..@apache.org
Subject svn commit: r589854 - /httpd/httpd/branches/2.2.x/STATUS
Date Mon, 29 Oct 2007 20:56:26 GMT
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
 



Mime
View raw message