apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: apr_table_t (was: Re: Release time?)
Date Thu, 20 Sep 2001 07:48:46 GMT
On Wed, Sep 19, 2001 at 09:55:56PM -0700, Justin Erenkrantz wrote:
> 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.  

I think both of you need to go back and look at that again.

    void *val;
    
    apr_hash_this(hi, NULL, NULL, &val);

How does that allow me to change the value in the hash table? Answer: it
doesn't. Of course, you can change whatever it points to, but you cannot
change the actual pointer-value.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message