Re: Tim Howes' 03.1.c: ldap_memfree/ber_free crashes

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 05:39 AM 6/9/99 +0100, Dr. Rich Artym wrote:
>No doubt there are good reasons for not providing an ldap_memfree()
>in OpenLDAP,

Because OpenLDAP 1.x maintains compatibility with LDAP software
which was designed to use the U-Mich API and its semantics.

>but sometimes in development it makes sense to accomodate
>purely pragmatic considerations in order to reduce subsequent support
>costs. This might be just one of those situations:  the OpenLDAP
>community will be asked about the "missing" function *thousands* of
>times in the next few years, and pragmatism says that if it is in
>any way possible to provide it then one should, just to reduce the
>future headache.

Okay, here:
#define ldap_memfree free

But, as you've already learned, this does not resolve the
difference in memory handling semantics between the Netscape
SDK and the U-Mich APIs.

>Furthermore, plenty of people will be wishing to migrate away from
>Netscape directory to a non-proprietary LDAP (that's one of my own
>team targets as well), and they will be hindered by issues like the
>above.

We are working at resolving differences between LDAP implementations.
Our approach is not to implement X from Netscape, Y from Microsoft,
and expect them to implement Z from us.   Our approach is to develop
and implement Internet standards governing LDAP and LDAP APIs.

Hence, you will see OpenLDAP migrate from U-Mich directly to
the IETF draft C LDAP API specification (OpenLDAP 2.0).  This
draft is close to becoming a standard track RFC.

>I suggest that if -lldap doesn't provide a direct plug-in
>replacement interface then a separate lib+include layer ought to be
>created in order to facilitate such migration.

I have no need or desire to provide such.  I'm focusing my
efforts on draft API specification and its implementation.

>Again, it's the pragmatic approach:

"pragmatic"... guided by practical experience and observation
rather than theory.

>it ought to be easier to
>provide this than to deal with the migration problems caused
>by the incompatibilities.

I plan to keep my older applications running under OpenLDAP 1.x
libraries indefinitely and develop new applications under
OpenLDAP 2.0.  I'll redesign and reimplement old applications
only as needed.

I suspect others will do whatever is right for them.

>[As for the core dump in ber_free(), I triggered an actual bug
> in 1.2.3, I presume?  Certainly the 03.1.c code seems innocuous.]

No.  Crashing in chunk free implies you called ber_free() on a
BerElement which was freed by the API.  Don't expect Netscape
SDK semantics from OpenLDAP 1.x.