cvs commit: apr/tables apr_hash.c

[wr...@apache.org]

wrowe       01/08/01 16:22:47

  Modified:    include  apr_hash.h
               tables   apr_hash.c
  Log:
    Almost used this when I thought our contents were going out of context.
    Turns out the hash contents were really corrupted by a request merge,
    but heck, this is still useful.
  
  Revision  Changes    Path
  1.27      +1 -0      apr/include/apr_hash.h
  
  Index: apr_hash.h
  ===================================================================
  RCS file: /home/cvs/apr/include/apr_hash.h,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- apr_hash.h	2001/07/19 03:45:33	1.26
  +++ apr_hash.h	2001/08/01 23:22:47	1.27
  @@ -195,6 +195,7 @@
                                              const apr_hash_t *overlay, 
                                              const apr_hash_t *base);
   
  +APR_DECLARE(apr_pool_t *) apr_hash_pool_get(apr_hash_t *hash);
   #ifdef __cplusplus
   }
   #endif
  
  
  
  1.21      +2 -0      apr/tables/apr_hash.c
  
  Index: apr_hash.c
  ===================================================================
  RCS file: /home/cvs/apr/tables/apr_hash.c,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- apr_hash.c	2001/07/19 03:45:33	1.20
  +++ apr_hash.c	2001/08/01 23:22:47	1.21
  @@ -380,3 +380,5 @@
       }
       return res;
   }
  +
  +APR_POOL_IMPLEMENT_ACCESSOR(hash)
  
  
  

Re: cvs commit: apr/tables apr_hash.c

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> wrowe       01/08/01 16:22:47
> 
>   Modified:    include  apr_hash.h
>                tables   apr_hash.c
>   Log:
>     Almost used this when I thought our contents were going out of context.
>     Turns out the hash contents were really corrupted by a request merge,
>     but heck, this is still useful.

Just an FYI, mod_mime is still subtly broken, I'm digging all the way into the
hash code to find out why.  ITMT, please continue to hold off on 2.0.23, or
jump in and help me :)  The brokenness is hiding somewhere in evaluating this
bit of code from find_ct;

        exinfo = (extension_info*) apr_hash_get(conf->extension_mappings,
                                                ext, APR_HASH_KEY_STRING);
        
        /* Check for Content-Type */
        if ((exinfo && ((type = exinfo->forced_type)))
            || (type = apr_hash_get(mime_type_extensions, ext,
                                    APR_HASH_KEY_STRING))) {
            r->content_type = type;
            found = 1;
        }

        /* Add charset to Content-Type */
>>>     if (exinfo && ((type = exinfo->charset_type))) {
            charset = type;
            found = 1;
        }

>>> BoundsCheker reports that we are looking at a dangling pointer, but the error
isn't making a whole lot of sense (it's invalid pointer diagnostic doesn't match any 
of the pointers at hand!?!)  This could be nothing more than a fluke in BC.

Bill