Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 19 Sep 2001 21:55:56 -0700
From: Justin Erenkrantz <jerenkrantz@ebuilt.com>
To: Brian Pane <bpane@pacbell.net>
Cc: dev@apr.apache.org
Subject: Re: apr_table_t (was: Re: Release time?)
Message-ID: <20010919215556.Q12417@ebuilt.com>
References: <20010919151902.2D44646DFD@koj.rkbloom.net>
 <3BA8DEE9.4070402@pacbell.net> <20010919112924.Q4050@lyra.org>
 <3BA8F130.7090004@pacbell.net> <20010919142804.D12417@ebuilt.com>
 <1000935512.9422.59.camel@griffon.cnet.com> <3BA9751E.7060502@pacbell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3BA9751E.7060502@pacbell.net>;
 from bpane@pacbell.net on Wed, Sep 19, 2001 at 09:48:30PM -0700

On Wed, Sep 19, 2001 at 09:48:30PM -0700, Brian Pane wrote:
> Following the pattern of the apr_hash_t iterator is fine with me, too.
> 
> But I just noticed a small problem with the apr_hash_t iterator:
> 
>   APR_DECLARE(void) apr_hash_this(apr_hash_index_t *hi, const void **key,
>                                   apr_ssize_t *klen, void **val);
> 
> The "val" is non-const.  Thus an app iterating through a hash table
> can overwrite a value with NULL.  That's probably bad, as it violates
> what otherwise is an invariant about apr_hash_t: values in it cannot
> be NULL.  If you pass a NULL value to apr_hash_set(), it deletes the
> key from the hash table, so it's ordinarily impossible to have a NULL
> value in a hash table.
> 
> I propose that we fix this by either:
>   * changing the hash iterator to a const iterator, or
>   * documenting it.

I think documenting it.

I thought we wanted it this way so that you could modify the value 
in the hash table without calling set or discarding the const.
If they set it to NULL, that's their problem.  

My $.02.  -- justin