[Date Prev][Date Next]
RE: ld_errno can no longer be determined -- ldap_perror is not appropriate (ITS#2584)
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
Symas: Premier OpenSource Development and Support
> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of firstname.lastname@example.org
> Full_Name: Karl Lehenbauer
> Version: 2.1.x (current)
> OS: FreeBSD
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (22.214.171.124)
> 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
> 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
> Finally, the ldap_initialize call is not documented in the
> manual pages. Most
> of the _ext functions are not documented, either.