Thanks for pointing out bugs in the code but i still cannot avoid accessing
reqVar->name since i have a mapping of OIDs to keys of my Objects in my db.
Since the keys used is not like a usual index-value pair, these mappings
needs to be maintained in my db.
But it still doesnt explain why i am getting zero padded OID when i print
reqVar->name inside the handlers?
On Jan 4, 2008 6:11 PM, Robert Story <[EMAIL PROTECTED]> wrote:
> On Fri, 4 Jan 2008 10:37:16 +0530 deepak wrote:
> DB>void clSnmpOidCpy(ClSNMPRequestInfoT * pReqInfo, ClUint32T * pOid)
>
> Here is one major problem.. An OID array is an array of longs, not int32.
> On a
> 64 bit system this means 8 bytes each, not 32, You should use the 'oid'
> type
> defined in the net-snmp headers.
>
> DB> /* COPY COLUMN OID FROM reqVar->name TO requestInfo.oid */
> DB> /* oidLen is tableoid length + depth till attribute oid. So,
> in this case depth till column will be 2.
> DB> 1-entry oid of table
> DB> 2-actual column. */
> DB> requestInfo.oidLen = OID_LENGTH (smCfgTblSim1TableOid) + 2;
> DB> clSnmpOidCpy(&requestInfo, (ClUint32T *) reqVar->name);
>
> I think this code is also troublesome, depending on what you are doing
> with
> requestInfo. Here, you are copying reqVar->name, which is the OID from the
> incoming request. This OID may have nothing to do with your table! Now, I
> haven't played with an iterator helper in a while, so it may be that the
> iterator helper, being its helpful self, has updated the requestVar with
> the
> correct OID. But in general, handler shouldn't examine this value.
>
> DB> index = table_info->indexes;
> DB> [...]
> DB> memcpy(& (
> requestInfo.index.smCfgTblSim1TableInfo.smCfgTblSim1IntIdx1),
> DB> (void *)index->val.integer, index->val_len);
>
> The same hold here. The table_info->indexes are the indexes of the
> incoming
> request, not the indexes for the current row. If you are using this value
> to
> figure out which object to get, you might be getting the wrong data.
>
--
Regards,
Deepak B.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
