On Thu, 28 Jul 2005 14:06:20 +0100 Dave wrote:
DS> > I´m pretty sure there isn´t a leak - the calling function should detect
DS> > if the pointer changed.
DS>
DS> Ummm... I don't think it does.
DS> [...]
DS> So the 'myString_get' routine is being passed the buffer from the
DS> varbind structure. If this buffer is pointing to some dynamically
DS> allocated memory (but not enough to hold the myString value), then
DS> the myString_get() routine will replace this with a larger buffer,
DS> but never try to release the original one.
That's inside the get_column() function. Go up the stack one, into
get_values().
DS> > The goal isn´t to be efficient, it´s to be easy to understand.
DS>
DS> Granted.
DS> But I'd say that the second of these is *much* easier to understand.
Don't get me wrong, I can definitely see the appeal.
DS> True - it mentions the dreaded word "SNMP". But it doesn't exactly
DS> require a large amount of knowledge of SNMP internals - particularly
DS> since the routine is generated automatically.
Yes, and in many instances the whole function is probably unnecessary, and
most of the time it won't need any modification at all. It could easily (and
more efficiently) be done in the interface code. But then you get into
configuration complexity for specifying which columns can be dealt with
internally vs needing the user hooks. (Not that I haven't thought of it, or
think it would be too hard to do. If only I had a cushy university job with
lots of free time... ;-) )
DS> The current code avoids making any mention of SNMP. But in doing so,
DS> it reveals a whole load of detail relating to the internal memory
DS> management. This might well be familiar to most C programmers - but
DS> it shouldn't be necessary for them to be bothered with it. Jumping
DS> through hoops to get rid of all trace of SNMP, ends up complicating
DS> the code unnecessarily, IMO.
I think the only thing complicating the code is that the values to be set are
pointers to something, and it deals with reallocation. I toyed with passing in
a buffer large enough to hold any data, and dealing with the memory allocation
in the interface file. But that would always require two memcpy calls, so I
opted to pass the var elements directly.
The other thing that makes me wary is that this code is generated in several
places, including others where there is no varbind involved. The idea being
that more special cases = more chances for bugs to sneak in.
DS> Anyway, what do other people think?
My other concern is the old slippery slope argument. Once we fall back on the
old familair net-snmp routine here, more places will be identified as
candidates.
But, in my continuing effort to be more conciliatory, if you can get Wes to
agree with you, I'll go along peacefully.
Please keep the suggestions and criticisms coming. I'm sure you'll find other
cruft that might more easily be weeded out.
--
NOTE: messages sent directly to me, instead of the lists, will be deleted
unless they are requests for paid consulting services.
Robert Story; NET-SNMP Junkie
Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders>
You are lost in a twisty maze of little standards, all different.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
