On Thu, 2 Jun 2005, Jean-Marc Desperrier wrote:

>> [...] So, in order to apply your patch, we need to make sure that we can
>> include the lber.h LDAP header, and then we need to make sure it exists and
>> then we need to extend the configure check and we then disable the ability
>> to run-time detect and use LDAP even when built on a system without LDAP.
>
> OK. After thinking some more about it, an architecture where the size of the
> first element is not equal to size_t would be seriously braindamaged, or
> trying to use a 32 bit LDAP from a 64 bit curl, with which the rest of the
> calls are not compatible anyway.
>
> So redefining it with size_t seems a reasonable solution.

You mean by providing our own struct? Yes, that could work. I guess that's a
fair work-around until someone fixes the LDAP code "properly".

>> [...]. It would also solve the nasty issue we have with possible ldap API
>> incompabilities.
>
> Well, that's your call.

No, it actually isn't. The current dynamic load system does not see API
changes and thus it can easily break (and this has been pointed out by various
people in various forums). Rewriting it to use the ldap lib like we use other
libs in libcurl would fix this potential problem, but *I* won't do that
rewrite. I don't ever use LDAP and I'll merely continue to point out that this
is a flaw... I have so many other itches I rather scratch! ;-)

> OK, then I can resubmit the patch with CURLOPT_LDAPNUMENTRY, inverted logic
> CURLOPT_TRANSFERTEXT, and redefining locally struct berval (maybe with the
> name struct curl_berval ?) using size_t for the first element.

Sounds like a fair approach!

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html