[AGENT++] GetNext MIB Column Retrieval: has_default() is not honored.

[Frank Fock]

Jens,

I think the code that resets the validity in the various 
MibTable::add_col methods
can be safely removed. But before I can release this change, I need to 
do some
more tests and also I encourage others to try out the change as shown below
in order to be sure that this change does not break other code out there.

Please remove the lines marked with DEL in mib.cpp:

void MibTable::add_col(MibLeaf* l)
{
    generator.add(l);
DEL    l->set_validity(0);
    l->set_reference_to_table(this);
}

void MibTable::replace_col(unsigned int i, MibLeaf* l)
{
    generator.replace_element(i, l);
DEL    l->set_validity(0);
    l->set_reference_to_table(this);
}

void MibTable::add_col(snmpRowStatus* rs)
{
    generator.add(rs);
DEL    rs->set_validity(0);
    rs->set_reference_to_table(this);
    row_status = rs;
}

Best regards,
Frank

Jens Engel wrote:

>I am just updating to Agent++ v3.5.22/23 (no change in 3.5.23 related to
>this issue).
>I have some problems with the "new" getnext visibility algorithm that is
>related to the validity checking of MibLeafs.
>
>There seems to be a small problem with the MibLeaf::validity attribute
>handling for READ-ONLY managed objects
>that have a default value. The current implementation resets the validity
>only for managed objects with READ-CREATE access.
>
>Implementation "call-sequence":
>1. MyColumn::InitCtor or DefaultCtor: Create my MIB column object: May set
>default value and indicate this via VMODE_DEFAULT.
>2. MibTable/Row::add_col(): Resets validity information to ZERO independent
>of DEFAULT (=> correct for row prototype).
>3. MibTableRow::CopyCtor (called by row->clone() when a new row is
>created):
>    Recreates validity information if access >= READCREATE and
>has_default() is true.
>
>NOTE:
>A normal column information will set the value of a cell (column instance)
>in a row.
>This will mark it as valid.
>
>On the other side, this may not be true for "MIB CONSTANTs" (Read-only
>columns) where value is only set by STEP 1 (above).
>These columns are never marked valid and are therefore not shown in a
>snmpwalk (via snmp getnext) MIB table traversal.
>Only explicit SNMP GetRequest will return their "hidden" values.
>
>Jens Engel
>
>
>_______________________________________________
>AGENTPP mailing list
>AGENTPP at agentpp.org
>http://lists.agentpp.org/mailman/listinfo/agentpp
>
>  
>