[Date Prev][Date Next] [Chronological] [Thread] [Top]


At 07:43 AM 10/18/2005, Ralf Haferkamp wrote:
>The 2.3 releases don't define LDAP_DEPRECATED anymore. This causes problems 
>with a lot of non-OpenLDAP software and I expect that many users of 
>libldap are not too happy about that especially because the man-pages for 
>many of the non-deprecated function are missing or just refer to the 
>deprecated calls (in fact I wonder why nobody has complained here 
>yet :) ). 

Maybe because defining -DLDAP_DEPRECATED in software that uses
deprecated interfaces is not that big of a deal.

As far as missing man pages, the community has yet needed them
badly enough to produce them (even though a few in the community
have complained that they are missing).  Maybe this will
encourage some man page writing.

>I know this has been discussed here already some time ago.

Yes, and the decision at the time was to define LDAP_DEPRECATED
in 2.2 release series.

>And for most of 
>the deprecated calls I understand the reasons for deprecating them (e.g. 
>no support for controls or in case of ldap_simple_bind no support for 
>password containing zero-values octets). But for some calls (e.g. for 
>ldap_init() and ldap_value_free() ) I wonder what the reasoning was to 
>deprecate them. Could someone clarify this for me?

ldap_init: use ldap_initialize(3) instead.  Aside from support
for ldaps:// and ldapi://, ldap_initialize(3), unlike ldap_init(3),
returns an indication of the nature of any error directly.

ldap_values_free(3): use of character strings for values is
deprecated as their use is quite bug prone as zero-valued
octets are legal in many LDAP syntaxes.  Note that NUL (U+0000)
is a Unicode character.  Bervals should be used instead (and,
hence, ldap_value_len_free(3)).

>BTW, even some of the OpenLDAP commandline tools (ldapsearch, -modify, ...) 
>still use some of the deprecated functions (though mostly only 

Fixing that been on the TODO list for ages.