Daniel Stenberg wrote:

> On Wed, 1 Jun 2005, Jean-Marc Desperrier wrote:
>
>> SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
>
> Heh, ok, now I understand your hesitation...

Oh, it's not that complex, the syntax makes it look worse.
Maybe I'd even better code it than continue discussing it much longer in
fact.

>> I don't think the size of the first element is guaranteed to be the
>> same on all platforms, so it's better to get it from the correct
>> include than redefining it.
>
> [...] 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.

> [...]. It would also solve the nasty issue we have with possible ldap
> API incompabilities.

Well, that's your call.

>>> Can't we make the type of output respect CURLOPT_TRANSFERTEXT instead?
>>
>> Yes, this is a good idea except that I understand
>> CURLOPT_TRANSFERTEXT defaults to binary, and here we really want to
>> default to ldif.
>
> Ah, right... I wonder if we could simply switch the default for LDAP.
> It feels really bad to add an option with basically the same meaning,
> only a reversed default value!

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.
Received on 2005-06-02