Re: (ITS#5540) Normalization assertion in attr.c

[unix.gurus@gmail.com]

Hi,

On Wed, Jun 4, 2008 at 2:20 PM, Hallvard B Furuseth
<h.b.furuseth@usit.uio.no> wrote:
> I haven't follwed this ITS, but a few notes anyway:
>
> unix.gurus@gmail.com writes:
>> monitorCounter
>> monitorCounter does not have an equality matching rule,
>
> Yes it does.  back-monitor/init.c line 1710.  What are you looking at?
> (Hmm, I too had the impression it had no EQUALITY rule...)

I'm working with OpenLDAP 2.4.9.

You're right.  integerMatch has an equality rule but no normalizing
function.  The logic that determines whether a normalized value should
exist says:
    have_norm = a->a_desc->ad_type->sat_equality != NULL &&

a->a_desc->ad_type->sat_equality->smr_normalize != NULL;
...
    new_nval = nvals != NULL;
...
if ( have_norm != new_nval ) {
    assert()

So we don't need nvals for integers.  For this reason I was right to
remove the nval for monitorCounter, monitorOpInitiated,
monitorOpCompleted, but my reasoning was wrong.

>> monitorOpCompleted
>> monitorOpInitiated
>> These attributes do not have equality matching rules,
>
> These do too, inherited from monitorCounter.

See above.

> it doesn't work right in 2.3 however:
>
> ldapsearch -LLL -bcn=monitor -s one '(monitorCounter=0)' monitorCounter
> dn: cn=Operations,cn=Monitor
> monitorOpInitiated: 231542983
> monitorOpCompleted: 231542982

I wonder if val is being maintained and nval is being left at 0.  The
code at the end of monitor_subsys_ops_update() maintains a_vals but
not a_nvals, so that is probably the problem:
        /* NOTE: no minus sign is allowed in the counters... */
        UI2BV( &a->a_vals[ 0 ], nInitiated );
        ldap_pvt_mp_clear( nInitiated );
...
        /* NOTE: no minus sign is allowed in the counters... */
        UI2BV( &a->a_vals[ 0 ], nCompleted );
        ldap_pvt_mp_clear( nCompleted );

>> namingContexts
>> configContext
>> dynamicSubtrees
>>
>> These attributes do not have equality matching rules, but probably
>> should.  I add 'EQUALITY distinguishedNameMatch' to them in
>> schema_prep.c.
>
> No, that breaks the definitions in the RFCs they come from.  (See their
> DESC strings.)  I don't know why they lack EQUALITY rules, maybe we just
> forgot when we defined them, but that's the way it is.  Same with
> supportedControl.

Ok, so we should not define nvals for them?

> monitorContext, readOnly and the olc* attributes are defined by OpenLDAP
> (their OIDs start with 1.3.6.1.4.1.4203) and can be modified if we feel
> like it.  Personally I prefer attrs to have the matching rules they can
> have unless there is a reason not to, but I didn't write these modules
> so I don't know if there _is_ a reason not to.

-- 
Thanks,
Sean Burford