Looking at the most current net-snmp code, it sure looks like upgrading will not help me. It looks like net-snmp demands that values defined as INTEGER in the MIB must be handed into net-snmp (i.e. with snmp_set_var_value() or snmp_set_var_typed_value()) using a long, i.e. 64 bits in a 64-bit environment. I have many, many variables in proprietary MIBs that are integers, and so I would have to change them all. Alternatively, I could write my own dumb little wrapper around snmp_set_var_value() and snmp_set_var_typed_value() that merely declared a long temp variable, set it equal to the passed-in int, and called the underlying net-snmp function with the new long and sizeof(long). Then, I figure, net-snmp would be happy.
Neither option seems elegant. Am I correct that everyone must do one of these, that net-snmp, even in its most recent version, forbids calling snmp_set_var_value() and snmp_set_var_typed_value() with INTEGERS given as 32 bits, if compiled for a 64-bit machine? You must use longs for INTEGERs in your internal structs, even when INTEGER is defined to be 32 bits and a long is 64 bits? This seems implausible to me, but true nevertheless. If I have to, I'll go with my dumb little wrapper idea, but I still hope I'm missing something. -John Gregg On 07/21/2010 11:59 AM, Robert Story wrote: > On Mon, 19 Jul 2010 18:04:06 -0400 John wrote: > JG> Thanks. But are you suggesting that I change the longs to int32_t > JG> throughout the baseline net-snmp code, the very exercise that the good > JG> folks at net-snmp thought was too onerous to take on? > > No, just in that one place to fix the error you currently face. > > JG> So my question really remains: what is the normal, expected way to deal > JG> with this? > > Upgrade to a more recent release. :-) > > JG> As hard as it would be to perform surgery on the > JG> net-snmp code, it would be about as bad to convert all our application > JG> level structs in this way. As I said (and it sounds like you agree) it > JG> looks like this issue is just as alive with the current code as it is > JG> with the old release I'm working with. > > I suggest just letting the compiler do the conversion where it will, and use > temporary variables where it won't. For the most part, the compiler will > handle it for you. > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
