[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ldap_first_attribute and ldap_next_attribute and ber_free
At 11:19 PM 11/3/99 -0600, Randy Kunkee wrote:
>The documentation for ldap_first_attribute and ldap_next_attribute
>says that they free the ber pointer when there are no more attributes.
(that is, when ldap_next_attribute() returns NULL)
>Below is ldap_next_attribute (from version 1.2):
>
>char *
>ldap_next_attribute( LDAP *ld, LDAPMessage *entry, BerElement *ber )
>{
> long len;
>
> Debug( LDAP_DEBUG_TRACE, "ldap_next_attribute\n", 0, 0, 0 );
>
> /* skip sequence, snarf attribute type, skip values */
> len = LDAP_MAX_ATTR_LEN;
> if ( ber_scanf( ber, "{sx}", ld->ld_attrbuffer, &len )
> == LBER_ERROR ) {
> ld->ld_errno = LDAP_DECODING_ERROR;
> ber_free( ber, 0 );
> return( NULL );
> }
>
> return( ld->ld_attrbuffer );
>}
>
>I would read this to say that ber_free is only freed when there
>is an LDAP_DECODING_ERROR. The only way the calling application
>would be able to tell the difference is to check ld->ld_errno.
>
>So is it guaranteed that if there is not a ber_scanf error, then
>ld->ld_attrbuffer != NULL, and that an LDAP_DECODING_ERROR indicates
>the end of the attributes (ie. not really an error per se)?
Exactly.
The LDAPext LDAP C API spec has been updated and these
requires a few changes to made to compliant. First,
ldap_next_attribute should never call ber_free(). Second,
ldap_next_attribute should not set the session error upon
successfully reaching the end of the attribute sequence.
The first has already applied to devel. I apply the second
when I get a chance (it's a simple matter of tracking the
number of bytes remaining in the BerElement).
One could argue that the second (and only the second) should be
applied to 1.2. However, this would likely break old code.
In general, changes to the 1.2 API should not be made. Broken
behavior will be preserved.
I wouldn't object to adding a clarification to the 1.2 manpage
which says that the API does not distinguish a decoding error
from no more attributes.
----
Kurt D. Zeilenga <kurt@boolean.net>
Net Boolean Incorporated <http://www.boolean.net/>