Edward Z. Yang wrote:
Hello all,
I was mucking around with OpenLDAP and noticed that ldap_get_values_len was returning NULL without setting a corresponding error code. Intruiged by this behavior, I did some debugging, and found that it was doing so on nsslapd-referral as generated by a Fedora 1.2.5 or 1.2.6 directory server for the cn=config entry (I haven't checked anywhere else yet). Here is a fragment of the byte sequence in ber_buf that was causing this:
000<14><04><10>nsslapd-referral1<00>0<19><04><12>passwordI checked some other code, ldapvi works around this by checking if the return value of ldap_get_values_len is NULL before using it, but it doesn't seem to do so consistently, and an old version of the code had this to say:
struct berval **values = ldap_get_values_len(ld, entry, ad); struct berval **ptr; if (!values) continue; /* weird server */I've also posted to 389-users [1], in Fedora Directory Server spitting out malformed data. But in that case, OpenLDAP should give me an error code, or work around it, or something.
Looking at the code and your data snippet, this is because your BER sequence says it's got a set of zero values. In this case, ber_scanf doesn't bother to allocate any memory to store the values, since there would be no point.
Technically there's no error here; sets are allowed to be empty. (E.g., if you had done an attrsOnly search then all of the attributes would have zero sets for their values.) So no, it's not a bug that libldap returns NULL instead of a pointer. And no, libldap shouldn't report an error code here either.
But it's certainly stupid for the server to attach the attribute to the response with no values, since this is obviously NOT an attrsOnly search response. Sounds like you ought to file a bug report against the Fedora Directory Server.
Cheers, Edward
[1] http://lists.fedoraproject.org/pipermail/389-users/2010-October/012320.html