Re: dyngroup return codes

[Howard Chu <hyc@symas.com>]

Aaron Richton wrote:

> So I've started playing with dyngroup in 2.3.2beta, and I have it working
> in the sense that things that I expect to hit my filter return TRUE from
> ldapcompare(1).
>
> However, things that don't hit return err=16 (No such attribute). For
> congruency, I would have expected FALSE. If it matters, err=16 is returned
> regardless of if the attribute I'm filtering on is present in the DN I'm
> comparing. (I could almost understand err=16 if the attribute wasn't
> present. The situation I'm envisioning as FALSE is attribute present but
> not equal to the filter.)
>
> In summary, with dyngroup filter: (a=a)
> (a: a) returns TRUE
> (a: b) returns No such attribute (but I imagined FALSE?)
> ({a not present in entry}) returns No such attribute
>
> Is there some technical reason behind this, or is it a bug, or am I not
> understanding the semantics of Compare right?
If you'll notice, the code for dyngroup will only execute if the current 
result code is in fact NoSuchAttribute. If your attribute of interest 
was already present in the entry, then the normal Compare operation 
would have yielded TRUE or FALSE and nothing would have been done in the 
overlay.

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support