RE: ld_errno can no longer be determined -- ldap_perror is not appropriate (ITS#2584)

[hyc@highlandsun.com]

The API and documentation are definitely in a poor state.
However, you can still rely on the LDAPv3 C API as described in
<draft-ietf-ldapext-ldap-c-api-05.txt> even though it's expired.
See the ldap_get_option() function with LDAP_OPT_ERROR_NUMBER.
(The draft calls this LDAP_OPT_RESULT_CODE, unfortunately...)

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of karl@superconnect.net

> Full_Name: Karl Lehenbauer
> Version: 2.1.x (current)
> OS: FreeBSD
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (65.208.17.245)
>
>
> The LDAP structure has been made opaque.  That's fine and I
> understand the
> reasoning.  It has opened up a couple of problems.  There is
> no way to get the
> ldap error code when you get an error where there is not a result.
>
> FOR EXAMPLE -- Call ldap_abandon and get a -1 result.  You
> used to be able to
> access ldap->ld_errno to find out the error number.
> ldap_perror (which is
> deprecated) can do this, but it access the internal ldap
> include file, not the
> exported one.
>
> I am trying to freshen and significantly upgrade the ldaptcl
> library to the
> latest stuff.
>
> There needs to be a way to fetch the error number out of the
> ldap structure when
> a result was not returned.  Perhaps there should be a new call, like
> ldap_errno.
>
> Also the ldap_open manpage still shows all sorts of fields
> that can supposedly
> be accessed in the ldap structure, but they can't -- this
> stuff should be
> removed.
>
> Finally, the ldap_initialize call is not documented in the
> manual pages.  Most
> of the _ext functions are not documented, either.
>
>