Re: Bug in LDAPObject.c, l_ldap_result()

[<mi...@st...>]

Derrick 'dman' Hudson wrote:
> On Sat, Jun 29, 2002 at 07:54:12PM +0200, Michael Str=F6der wrote:
> | This whole stuff with result() is somewhat=20
> | incomplete anyway since the result type
>=20
> Looks like your sentence was cut off.

The result type is not returned in search results when using=20
search_s() which is somewhat incomplete. Search results may=20
contain real entries and search continuations. One has to=20
distinguish that by looking at the type (tuple vs. string). But=20
that's not nice.

> The CVS version of python-ldap doesn't work for me, though.  I had to
> change some of the sasl stuff in LDAPObject.c for it to compile,

Hmm, which version of OpenLDAP? I usually compile against CVS=20
version checked out from REL_ENG_2 branch. That works smoothly.

Can you post your SASL-related changes?

> and I get a SEGV with web2ldap.

Did you check http://www.web2ldap.de/faq.html ?

-------------------------- snip ---------------------------
web2ldap crashs a lot of with segmentation faults.

This is not a web2ldap issue. Please check how your Python=20
interpreter was compiled. It has to be build with configure=20
--without-pymalloc. You probably have to rebuild all C extension=20
modules involved afterwards.
-------------------------- snip ---------------------------

 > (I also changed a couple other minor
> details that gcc complained about)

Again: Post these changes for open discussion.

> | Yes. But then the application has to handle that.
>=20
> Isn't that the purpose of not blocking in the first place?
>=20
> | The non-blocking version of LDAPObject.result() is the one which
> | needed the time.sleep() hack.
>=20
> The version that was in release 2.0.0pre04 was blocking if all was
> true.  It just did the blocking in python/python-ldap instead of in
> C/libldap2.

Yes. My wording was rather misleading. Blocking yes, but not=20
locking all the time. Therefore other threads calling into the=20
LDAP libs are allowed to run although one thread is blocked.

> | >I also think the C function needs
> | >to be modified to treat Py_None as NULL to allow python code to
> | >specify a timeout that is indefinitely long.
> |=20
> | IMHO that's done with timeout=3D-1. Looking at l_ldap_result() in=20
> | LDAPObject.c it seems to be implemented correctly
>=20
> Ahh, yeah, that is one suitable convention.  Doesn't
>     timeout=3DNone
> sound amusingly accurate though?  (in english at least)

Well, I have no clue why David chose -1 instead of None.

Ciao, Michael.