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/
