I just did a quick review of the deref control code. I thought we had already established this policy since the OpenLDAP 2.1 days: no more naked char *'s in new code. Always use struct bervals, never discard information you're going to need again later, and never recompute it if you already have it in hand. Every string sent thru the protocol is already accompanied by its length; it's stupid to call strlen() on any result we receive.
Seems that publishing this in RE24 was a bit premature, sorry I didn't catch this sooner.
On a related note, I'm still not so thrilled with the STRLENOF() macro. Most of the time I use sizeof("strconst") because I *know* there's a trailing NUL and I *want* it incorporated in the result...
-------- Original Message -------- Subject: (ITS#6233) print_deref assertion if no deref attributes returned Date: Tue, 28 Jul 2009 17:43:40 GMT From: rmeggins@redhat.com To: openldap-its@openldap.org
Full_Name: Rich Megginson Version: 2.4.17+ (current HEAD) OS: Fedora URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.113.59.19)
I am testing the LDAP Dereference feature specified here - http://www.openldap.org/devel/cvsweb.cgi/~checkout~/doc/drafts/draft-masarat...
I am getting an assertion in common.c at line 2077: 2074: ptr = lutil_strncopy( ptr, dr->derefVal.bv_val, dr->derefVal.bv_len ); 2075: *ptr++ = '\n'; 2076: *ptr++ = '\0'; 2077: assert( ptr <= buf + len );
tool_write_ldif( LDIF_PUT_COMMENT, NULL, buf, ptr - buf);
In my test, ptr is one greater than buf + len. It appears that len does not take into consideration the addition of the trailing \0 at line 2076. My test is looking for a dereference attribute which does not have any values, so that the attrVals in the control response is empty. If there are values to return in attrVals, the assertion is not triggered.