[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ITS#3985 test039 hangs on Windows

At 02:47 PM 10/7/2005, Howard Chu wrote:
>Kurt D. Zeilenga wrote:
>>>And in ldap_parse_result in libldap/error.c, as I've already pointed out, we queue responses with their originating requests. Any LDAP Request can only have one Result message, regardless of how many intermediate messages may be included. So it appears that all accomodation for this LDAP_MORE_RESULTS_TO_RETURN error code is just excess baggage.
>>>    
>>
>>The only thing I can think it exists for handling of
>>message chains containing responses in reply to
>>multiple requests.
>>
>>  
>Hmmm. But libldap never constructs chains in such a fashion; responses are only chained to their originating request. And there are no APIs for an external caller to link two separate chains together.

What about the case where ldap_result(3) is called for any and
all?  The message chained returned could contain responses
from multiple requests.

>Also, in the C API draft section 14 "Handling Errors and Parsing Results" it says "If a chain of messages that contains more than one result message is passed to these routines the always operate on the first result in the chain." And more importantly "If a value other than LDAP_SUCCESS is returned, the values of all the result parameters are undefined."
>So if you somehow got hold of an aberrant chain with more than one result in it, our ldap_parse_result() would parse the first result (as expected) and then discover the subsequent result, then return LDAP_MORE_RESULTS_TO_RETURN which would totally invalidate all the parsing it did on the first result.

Given how I think it was meant to be (which may not be how it was
meant to be :-), it likely should have said "LDAP_SUCCESS or LDAP_MORE_RESULTS_TO_RETURN".

>Obviously trying to make sense out of things based on an old broken API spec may not be very fruitful. But one way or another it should make more sense than it currently does.

I concur.  I suspect few if any clients actually deal with
LDAP_MORE_RESULTS_TO_RETURN as (I believe) was intended.


>-- 
> -- Howard Chu
> Chief Architect, Symas Corp.  http://www.symas.com
> Director, Highland Sun        http://highlandsun.com/hyc
> OpenLDAP Core Team            http://www.openldap.org/project/