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

["Dr. Rich Artym" <openldap-bugs-mail@galacta.demon.co.uk>]

In Message-ID: <3.0.5.32.19990608105658.00a3a480@localhost>, Kurt writes:

> The examples in the Howes' bookS are targetted at the Netscape SDK.
> The Netscape SDK has significantly different from the U-Mich API
> which OpenLDAP 1.x is compatible with.  Hence, you will have to
> make a number of changes to these examples to get them to work
> under OpenLDAP 1.x (which uses a Umich 3.3 compatible API).

OK, thanks for that advice.  If I recall correctly, Howes' book
targets both the Netscape and Umich implementations running under
Unix, Microsoft and Macintosh.  Although I've only just begun to
read it, the impression I get is that he's trying for genericity.

In any event, I'll be creating my own instrumented versions of
his examples as a way of gaining a good understanding of what's
going on.  Where a divergence with OpenLDAP appears, I'll have
to write a simple abstraction interface to maintain portability
across all these major implementations.

> >I followed the advice I found there and #defined ldap_memfree()
> >to use free().
> 
> Unfortunately, it's not that simple.  You need to change some to
> free(), make some conditional on results, and remove others.

No doubt there are good reasons for not providing an ldap_memfree()
in OpenLDAP, 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.

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.  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.  Again, it's the
pragmatic approach:  it ought to be easier to provide this than to
deal with the migration problems caused by the incompatibilities.

> I recommend you read the Appendix D, "Known Incompatibilities
> with RFC1823" of the IETF C LDAP API draft.  The draft is
> available at http://www.ietf.org/.   Netscape SDK memory
> handling is similiar to this draft, U-Mich API is similiar to
> RFC1823.  You may also want to search Netscape's devedge
> site.  They might have U-Mich -> Netscape porting document
> which might help (you'd use it in reverse).

I'll do that -- many thanks for this very comprehensive advice!

> OpenLDAP 2.0 SDK will be adhere closily to the IETF draft spec
> (hopefully both will be completed soon).   You might want
> to toy around with OpenLDAP-devel (bleeding edge code),
> it's API is quite similiar to the IETF draft spec (though
> not yet LDAPv3).

I'll do that too, as I intend to get thoroughly acquainted with
the whole area.  Thanks again!

[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.]

Cheers,

Rich Artym
rich@galacta.demon.co.uk