[Date Prev][Date Next]
Re: commit: ldap/clients/tools common.c common.h
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.
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
>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:-)