apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From traw...@apache.org
Subject cvs commit: apr/tables apr_tables.c
Date Fri, 18 Jan 2002 21:57:36 GMT
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) {
  
  
  

Mime
View raw message