Robert,
I've been doing a bit more work with the 'array-user' framework,
and have got a couple of questions about it, if you have the time
(and can remember about this!)
The first relates to the return value of the 'delete_row'
routine. This is defined as returning a 'netsnmp_index*',
which elsewhere tends to be used for passing the per-row
data structure.
Judging by the mib2c-generated code, the purpose of this routine
is to release the memory used by that data structure. So it probably
wouldn't be safe to follow the row pointer afterwards.
What should this routine return:
a) if deleting the row succeeds ?
b) if deleting the row fails ?
The second question concerns the 'all_helpers.h' consolidated
header file. That file includes a reference to the 'table_array.h'
header file, but this is commented out. Can you remember why?
This doesn't matter when using the mib2c-generated output, which
explicitly pulls in this header file as part of the table-specific
header file. But if this #include is put in the code file instead
(which is typically what's done for most of the other helpers),
then compiling 'mib_module.c' gets confused.
Is there any reason why 'all_helpers.h' shouldn't include
this helper along with all of the others?
I've also noticed some minor inconsistencies between the prototype
definitions of some of the hook routines in this header file, and
the code generated by mib2c. The hooks are mostly defined using
'netsnmp_index*' parameters (apart from the row_copy and row_compare
hooks, which use 'void*')
But the mib2c output defines routines using the table-specific
context data structure. This mismatch seems to irritate the compiler,
unless the relevant hook assignments are explicitly re-cast (as they
are in the mib2c output).
This feels a little risky and/or potentially confusing - is it
perhaps worth tweaking the mib2c.array-user.conf file to bring
the generated code into line with the header expectations?
Obviously, that would need explicit casts of the parameters to
get them into a form that could actually be used. But this feels
a slightly cleaner approach.
One other thought - the generated 'row_copy' routine includes code
to duplicate the index OID array. Is this strictly necessary?
This routine seems to be used to take a copy of the previous
contents of a row, so it can be restored if processing the SET
request fails. But this assignment won't affect the index values
(or any of the non-writeable column objects come to that).
So is there any real need to copy these values across and back?
Dave
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
