Some wishes for RE25:
Expose most LDAP_DEPRECATED functions again. This code is not going away, or it'd be gone by now after 16 years of deprecation. I usually #define LDAP_DEPRECATED anyway. What's the point of trying to make me pass 2 extra NULL args to a bunch of functions? And making a "SASL bind" function the proper way to do Simple Bind is silly and confusing. OTOH some depreciation make sense, like ldap_get_values() which returns char** instead of berval**.
Add --enable-cldap as "experimental". Add tests and some fixes. The CLDAP code isn't going away either, so i seems better to support it properly. People are submitting libldap ITSes, but slapd and ldapsearch usage remain broken. slapd looks easy to fix, ldapsearch depends on vestiges of libldap code to ignore Bind requests. Dunno if I want to bother tracking that down in libldap or just omit the Bind in ldapsearch. Maybe RedHat has a fix.
...or do the opposite, kill LDAP_DEPRECATED and CLDAP. I hope not, but that's better than eternally deprecated/code-rotting features.
Kill K&R1 support, i.e. the LDAP_P(()) stuff. Supposedly the headers support K&R1, but OpenLDAP-2.0 broke this (ITS#6171). Nobody has cared enough to fix it, and I refuse to fix it.
See if we can require C99 to build OpenLDAP, but keep the headers C90-compliant. In particular, replace Debug() with a varargs macro, initially without changing the calls to Debug(). If we get away with that, we can kill the extra ,0,0,0 arguments to Debug() later so gcc -Wformat will catch missing/spurious args.
--On Tuesday, June 16, 2015 6:51 PM +0200 Hallvard Breien Furuseth h.b.furuseth@usit.uio.no wrote:
I wrote:
...or do the opposite, kill LDAP_DEPRECATED and CLDAP. I hope not, but that's better than eternally deprecated/code-rotting features.
That is, kill the LDAP_DEPRECATED functions.
I'd vote for killing the deprecated functions from 2.5, although I agree it'd be nice to keep a trivial wrapper specificaly for simple binds. I rarely see traffic from people any longer on how to convert code using them to the new functions (I.e., the majority of code utilizing libldap seems to have moved to the non-deprecated fuctions). Neither RH nor Debian appear to default to compiling with them enabled, so the numerous packages that link to libldap(_r) must have migrated off of them as well.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 21/06/15 02:33, Quanah Gibson-Mount wrote:
I'd vote for killing the deprecated functions from 2.5, although I agree it'd be nice to keep a trivial wrapper specificaly for simple binds. I rarely see traffic from people any longer on how to convert code using them to the new functions (I.e., the majority of code utilizing libldap seems to have moved to the non-deprecated fuctions). Neither RH nor Debian appear to default to compiling with them enabled, so the numerous packages that link to libldap(_r) must have migrated off of them as well.
Linking is irrelevant. libldap(_r) always includes the functions. The user #defines LDAP_DEPRECATED to expose their prototypes in ldap.h.
On Sat, Jun 20, 2015 at 05:33:50PM -0700, Quanah Gibson-Mount wrote:
I rarely see traffic from people any longer on how to convert code using them to the new functions (I.e., the majority of code utilizing libldap seems to have moved to the non-deprecated fuctions).
Out of 151 packages in Debian main that build-depend on libldap, 77 mention LDAP_DEPRECATED. I didn't check all of these, but the ones I looked at all seemed to be activating it.
http://codesearch.debian.net/perpackage-results/LDAP_DEPRECATED%20-package%3...