[Date Prev][Date Next]
Re: Tim Howes' 03.1.c: ldap_memfree/ber_free crashes
At 05:39 AM 6/9/99 +0100, Dr. Rich Artym wrote:
>No doubt there are good reasons for not providing an ldap_memfree()
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
#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
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.