At 07:43 AM 10/18/2005, Ralf Haferkamp wrote: >Hi, > >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 >ldap_perror). Fixing that been on the TODO list for ages. Kurt
