Even though it isn't a big deal, the point is that newcurl is not undefined. It was initialized to NULL when it was declared at the beginning of the function. This is a mismatch between HEAD and APACHE_2_0_BRANCH. util_ldap has been moved out of experimental in HEAD and now exists in modules/ldap. jorton is refering to the r1.7 revision of modules/ldap/util_ldap_cache_mgr.c rather than modules/experimental/util_ldap_cache_mgr.c. The backport should include the initialization of newcurl as was committed in modules/ldap/util_ldap_cache_mgr.c r1.7 rather than the "else" code submitted in the patch file so that the backport matches the current state of the code.
Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Monday, September 20, 2004 7:15:27 AM >>> See my util_ldap.c patch. Whether or not this patch is absolutely necessary, leaving code paths that leave function return results undefined is never good! Also, see the bigger patch to util_ldap_cache_mgr.c that I passed along yesterday. I've attached both here for convenience. -- Jess Holle Joe Orton wrote: >On Sun, Sep 19, 2004 at 11:00:25PM -0000, [EMAIL PROTECTED] wrote: > > >> --- util_ldap_cache_mgr.c 13 Sep 2004 11:11:32 -0000 1.8 >> +++ util_ldap_cache_mgr.c 19 Sep 2004 23:00:25 -0000 1.9 >> >> >... > > >> @@ -252,6 +254,8 @@ >> newcurl = util_ald_cache_insert(st->util_ldap_cache, &curl); >> >> } >> + else >> + newcurl = NULL; >> >> return newcurl; >> } >> >> > >This is not necessary after the r1.7 fix last week, so there's no point >in asking for r1.7 to be back-ported as well as this. > >Also it looks as if the _child_init hook in util_ldap.c will still >segfault with a NULL _cache_lock? > >
