I suspect this change will only cause problems in otherwise broken client programs. IIRC, there are other cases where NULL can be returned. Returning it in another should not be a problem.
Kurt At 06:53 AM 11/5/2005, Hallvard B Furuseth wrote: >Pierangelo Masarati writes: >>On Sat, 2005-11-05 at 05:29 -0800, Kurt D. Zeilenga wrote: >>> Yes. Given that matched and DN come from non-optional >>> protocol fields where empty indicates no value (ugh), >>> we should return NULL instead of ->"". >> >> I suggest we start experimenting with HEAD by adding a >> LDAP_NULL_IS_NULL macro that's defined #ifdef LDAP_DEVEL. > >The C API has quite a number of quirks. I do not think this change >alone is enough of an improvement to be worth the breakage it risks in >existing correct clients - even if it fixes a number of existing broken >clients. > >If the API changes a small change now and a small change then, it can be >hard for client maintainers to keep track. A safer way - either for >just this change or whatever collection of changes we come up with for >now - might be to enable it through something like ldap_set_option(, >LDAP_X_API_USER_OPTIONS, &<bit flag of changes from the original>). > >(Bye for now, diving back to a bunch of internet-drafts which I should >have been going through:-) > >-- >Hallvard
