Thanks. But are you suggesting that I change the longs to int32_t
throughout the baseline net-snmp code, the very exercise that the good
folks at net-snmp thought was too onerous to take on? I'm hesitant to
change that so far untouched code, although I did look into that very
possibility. Problem is, that you of course end up changing lots and
lots of things from long to int32_t far and wide throughout net-snmp.
I'm daunted at the prospect, what with regression testing the whole
library, destabilizing the working (if old) net-snmp, etc.
So my question really remains: what is the normal, expected way to deal
with this? How do most people compile net-snmp on 64 bit systems? Do
they simply use longs (rather than ints, as we did) internally in all
their structs to hold values that are ultimately declared to be INTEGER
in all the MIB files? As hard as it would be to perform surgery on the
net-snmp code, it would be about as bad to convert all our application
level structs in this way. As I said (and it sounds like you agree) it
looks like this issue is just as alive with the current code as it is
with the old release I'm working with.
I'm still holding out hope that my whole take on this situation is
wrong, and there is a simple way to deal with this. Surely other systems
using net-snmp who store their INTEGERs as int have cut over to 64 bits?
-John Gregg
On 07/19/2010 05:39 PM, Robert Story wrote:
> On Mon, 19 Jul 2010 12:03:00 -0400 John wrote:
> JG> But later, deep in the net-snmp code, at the top of the routine
> JG> asn_build_int(), we fail this sanity test:
> JG>
> JG> if (intsize != sizeof(long)) {
> JG> _asn_size_err(errpre, intsize, sizeof(long));
> JG> return NULL;
> JG> }
>
> Just change those longs to int32_t.
>
> JG> INTEGER is 4 bytes, now and forever, right? The ASN.1 protocol doesn't
> JG> change just because the underlying machine architecture changes.
>
> Yep, but long is used almost everywhere in the code, and a decision was made
> not to try and change them to a 32bit type. There are probably many many more
> 32/64 bit issues in that release, waiting to byte you. (sorry, couldn't
> resist!)
>
> Robert
>
------------------------------------------------------------------------------
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
