On Thu, 2005-10-20 at 08:20 -0700, Wes Hardaker wrote:
> >>>>> On Thu, 20 Oct 2005 10:30:07 +0100, Dave Shield <[EMAIL PROTECTED]>
> >>>>> said:
>
> Dave> So the "natural" representation of an IP address (on Linux, at least)
> Dave> *is* an integer. Though that header file doesn't seem to indicate
> Dave> whether this should be host-order or network-order. :-(
>
> I was talking about *our* routines. IE, the SNMP data type is a 4
> byte string not an integer.
Unfortunately, it's not that simple.
Some of our API calls assume an IP address is held internally as
a string value. Others regard it as an integer. We are definitely
not being consistent!
Checking the 'snmplib' code for "IPADDR", gives the following:
mib.c:
lines 1635ff sprint_realloc_networkaddress
string
lines 1705ff sprint_realloc_ipaddress
string
lines 3470ff build_oid_segment
integer
lines 3675ff parse_one_oid_index
integer (for setting the value)
string (debug output immediately after!)
parse.c:
(nothing relevant)
snmp_api.c:
lines 3177ff snmp_pdu_build
string
lines 3450ff snmp_pdu_realloc_rbuild
string
lines 4434ff snmp_pdu_parse
string
lins 6718ff snmp_add_var
integer
snmp.c:
lines 269ff snmp_build_var_op
string
lines 372ff snmp_rbuild_realloc_var_op
string
snmp_client.c:
lines 785ff snmp_set_var_value
integer
(the other places IPADDR occurs aren't relevant to this discussion)
So bearing in mind that most of the building routines come in pairs
(and ignoring the debug output call), it's actually equally split
between integer and string-based interpretation of the value!
> Hence the confusion because some APIs
> (unix) expect an int, and some (SNMP) expects a string. The
> interface (net-snmp) is thus stuck holding the bag.
We really ought to put our own house in order, before we start
pointing the finger elsewhere :-)
It would be quite reasonable to decide to use either style of
representation for an IP address:
- treat it as an integer
(and convert to/from the string format
when working with low-level SNMP packets)
or
- treat it as a four-byte string
(and convert to/from the integer form
when working with in_addr_t variables)
My gut reaction is that it would probably be simpler in the
long run to hold such addresses internally in the natural
form (i.e. as an integer), and convert them to the string
equivalent when building or parsing SNMP packets.
There are relatively few places where this would need
to be done, and they're all deep in the heart of the SNMP
library, where we can control what's happening. Holding
addresses in the string form implies doing the conversion
at the "top" of the library, where there's more risk of
application programmers doing the Wrong Thing.
Though I've no great aversion to consolidating on a
string-based internal representation either. That might
possible be slightly simpler to achieve in the short term.
But we should really decide on one form, and *stick* to it!
Dave
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
