On Tue, 2004-08-24 at 20:42, Robert Story wrote:
> On Tue, 24 Aug 2004 15:32:33 +0200 (CEST) Jochen wrote:
> JF> Yes. There seem to be some more cases where Counter32 or Counter64 aren't
> JF> handled correctly. This one has also been reported:
> JF>
> JF> snmpd returns Counter32 values with more than 32 bits on alpha.
>
> Ack! Is there a bug report for this one?
>
> I'm guessing this a 64 bit system, where a long is 64 bits?
>
Ok so this is a little different to the sparc64 example. The sparc64
userland code (for net-snmp at least) is compiled as 32 bit code i.e.
ilp32 (int, long and pointer are 32 bit). So the problem that I was
seeing was that it was not parsing a kernel 64 bit number correctly.
But I'm guessing that the alpha userland is compiled as 64 bit. In that
case there are lots of holes.
All of interface.c uses ulong and long for the values. Hence if the
kernel reports > (2^32)-1 then you get that value reported upwards.
> I think we are going to continue to find lots of little gotchas on 64 bit
> systems until someone has the time to take a good hard look at the code.
> Unfortunately, this is not a problem that is specific to a particular file or
> module, so it is a daunting task.
Indeed
> As part of that daunting task, I've argued for using types with explicit sizes
> where appropriate, instead of the now ambiguous long, but the idea hasn't gone
> over very well. So we have to hit the 64 bit gotchas one at a time, as they
> come up.
Ouch. I've been bit so many times with word sizes that I always tend to
use fixed sizes these days whenever we are talking about interfaces that
use specific sizes.
>
>
> This one, I'm guessing, is one of (probably lots and lots) the places in the
> code where it is assumed that sizeof(long) == 4. The ASN library code should
> probably have some checks added to make sure it doesn't pass accept integer
> values that are larger than 32 bits.
Indeed. I've had a quick look at asn_build_unsigned_int() in
snmplib/asn1.c and it looks totally broken when sizeof(long) != 4. Sure
it marshalls the data fine but it can certainly pass data that is
greater than 32 bits.
asn_build_int() and asn_build_unsigned_int() are definitely broken when
compiled with long = 64 bit.
>
> I'm also assuming the example snmpwalk you gave above was run on the same box,
> or another 64 bit box. What happens when the snmpwalk is run on a 32 bit
> machine? I'd bet the library chokes on the value that is over 32 bits.
>
A quick look at the code of asn_parse_int shows that this is the case
if ((size_t) asn_length > intsize) {
_asn_length_err(errpre, (size_t) asn_length, intsize);
return NULL;
}
>
> JF> One reference on how to fix these ones would help ;-)
>
Sounds like a lot of pain is coming when more things use 64 bit
userland.
Richard
> Given that we can't use explicit sizes, the other solution, taken from the
> interface code, seems to be something like this:
>
> long actual, safe;
>
> actual = get_some_value();
> safe = actual & 0xffffffff;
>
> return safe;
>
> Hopefully the other core developers will thrown in their 2 cents/pence as well.
--
[EMAIL PROTECTED]
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Net-snmp-coders mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
