trawick 02/01/18 13:57:35
Modified: tables apr_tables.c
Log:
for the call to apr_table_overlap where it has no work to do:
avoid some logic in apr_table_overlap which dies with
APR_POOL_DEBUG+ElectricFence since it tries to alloc zero
bytes
it is useful to bail out early anyway to avoid some needless
function calls and other
Requesting CGI scripts through Apache causes such a call (maybe
just for HTTP/0.9? I dunno.).
Revision Changes Path
1.22 +12 -0 apr/tables/apr_tables.c
Index: apr_tables.c
===================================================================
RCS file: /home/cvs/apr/tables/apr_tables.c,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- apr_tables.c 9 Dec 2001 00:52:19 -0000 1.21
+++ apr_tables.c 18 Jan 2002 21:57:35 -0000 1.22
@@ -935,6 +935,18 @@
apr_table_entry_t *elts;
max_keys = a->a.nelts + b->a.nelts;
+ if (!max_keys) {
+ /* The following logic won't do anything harmful if we keep
+ * going in this situation, but
+ *
+ * 1) certain memory debuggers don't like an alloc size of 0
+ * so we'd like to avoid that...
+ * 2) this isn't all that rare a call anyway, so it is useful
+ * to skip the storage allocation and other checks in the
+ * following logic
+ */
+ return;
+ }
cat_keys = apr_palloc(b->a.pool, sizeof(overlap_key) * max_keys);
nhash = DEFAULT_HASH_SIZE;
while (nhash < max_keys) {
