On Mon, 21 Oct 2002, Aaron Bannert wrote:
> On Tue, Oct 22, 2002 at 02:23:20AM -0000, Ryan Bloom wrote:
> > rbb 2002/10/21 19:23:20
> >
> > Modified: include apr_errno.h
> > memory/unix apr_pools.c
> > Log:
> > Allow people who use userdata to distinguish between a successful
> > retrieval
> > from the pool userdata, and not being able to retrieve. We could also
> > separate out when the hash doesn't exist, but I have left that for
> > somebody
> > else.
> ...
> > - if (pool->user_data == NULL)
> > + if (pool->user_data == NULL) {
> > *data = NULL;
> > - else
> > + }
> > + else {
> > *data = apr_hash_get(pool->user_data, key, APR_HASH_KEY_STRING);
> > + }
> > +
> > + if (*data == NULL) {
> > + return APR_KEYNOTFOUND;
> > + }
> >
> > return APR_SUCCESS;
> > }
>
>
> Isn't this going to break something? The find_entry() function isn't
> able to tell the difference between an unset key and a NULL value,
> so why do we pretend to know the difference here? There are a bunch of
> places that I see in thread.c, threadpriv.c, and sockets.c that will
> start returning errors now where before they didn't, just because
> the error != APR_SUCCESS. Am I seeing this correctly?
If you try to get a value from the table, and the value isn't set, then we
shouldn't return NULL. The fact that we can't determine the difference
between a NULL entry and an unset key is proof that the hash table API is
incorrect. We should fix the API ASAP. I don't see the code in
thread.c, threadpriv.c, and sockets,c that may break. The only place that
those files call these functions is when we are exposing the userdata in
the pool inside the incomplete type.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
