On Thu, 2005-07-21 at 09:07 -0400, Robert Story wrote: > On Wed, 20 Jul 2005 17:02:24 +0100 Dave wrote: > DS> I've been doing a bit more work with the 'array-user' framework, > > Yeah, I noticed the cvs activity and knew what section of the book you were > working on. :-)
Shucks. And there was I hoping you wouldn't notice..... > DS> The first relates to the return value of the 'delete_row' > DS> routine. This is defined as returning a 'netsnmp_index*', > Yep. And the return value is hard-coded to NULL. I can only guess > that maybe originally it was a remove funtion that was re-tooled, > and the prototype didn't get changed. It should be void. That's sort of what I suspected. So the obvious followup question is: Should we "fix" this, or just grin and bear it? > DS> The second question concerns the 'all_helpers.h' consolidated > DS> header file. That file includes a reference to the 'table_array.h' > DS> header file, but this is commented out. Can you remember why? > > Nope. Wes created the file, and it was commented out when he created it. > I can only guess that it caused compile problems at the time... > > DS> Is there any reason why 'all_helpers.h' shouldn't include > DS> this helper along with all of the others? > > Not that I can think of. OK - so how about we uncomment that #include, and wait for Wes to cotton on? > DS> I've also noticed some minor inconsistencies between the prototype > DS> definitions of some of the hook routines in this header file, and > DS> the code generated by mib2c. > This was a conscious decision. The prototypes for the hooks, obviously, must > use the netsnmp_index, because the hooks are the same for all tables. (apart from 'row_copy' - why was that defined differently?) > But it seemed silly to define the functions w/netsnmp_index, and then > have to immediately create a local var and cast the parameter. Hmmm... OK, I sort of see what you mean. > So the generated functions use the actual type for the particular table. > If there are missing casts that bug the compiler, they should be fixed. No - that's fine. The structure of this chapter of the book is such that I'm actually discussing manually generated array-user code (comparing it against assorted earlier examples, as well as the mib2c output). There's nothing wrong in the mib2c output - just my code. As long as I understand the thinking behind this approach, I can probably describe it reasonably clearly. > DS> One other thought - the generated 'row_copy' routine includes code > DS> to duplicate the index OID array. Is this strictly necessary? > DS> .... But the assignment won't affect the index values > DS> (or any of the non-writeable column objects come to that). > DS> So is there any real need to copy these values across and back? > > I think all the values must be copied, since the processing of a settable > variable could very well result in a change to a read-only variable. OK - that's a possibility I hadn't thought of. Unlikely, but possible. (You're even more warped than I am, at times!) > As for the indexes, you are correct that the current use by the helper could > get away without the indexes. But the function is more generic, and I think a > row copy function should copy the entire row. And at this late stage of the > game, I'd really rather not change functionality of existing functions. Fair enough. It's probably not particularly important, and I don't think it's worth adding further complexity to this helper just to save a bit of unnecessary processing. I'll probably stick with a minimal copy routine (for simplicitly), and just mention that the mib2c output does a somewhat fuller job. I'm trying to keep this particular section as short as possible. It's the MfD discussion that looks set to expand dramatically..... (But that's one for another day) 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 [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
