Re: [RFC PATCH] Ensure oid sub-ids are always 32bit

>>>>> On Tue, 15 Apr 2008 16:41:01 +0100, Alex Bennee <ajb-ml@cbnl.com> said:

AB> Besides if external code is using u_long as it's base type I'm tempted
AB> to say they deserve what they get.

Actually, I'm sure much of it was copied from bad code in the project.
So I'm not sure they do.

AB> oid_size_warning.c:8: warning: initialization from incompatible pointer
AB> type

AB> It should be a big enough clue.

Assuming a compiler that warns you.

(count the compiler warnings in the base code before you throw stones at
people needing to watch for compiler warnings ;-)

We clean them up on a regular basis (Ok, Niels does most of it) and they
keep creeping back in.

>> Generally, the ASN and relate library code should always do the right
>> thing internally if it's passed a proper u_long where it's been expected
>> (for a very very long time; predating most of us (including me) working
>> on the project).

AB> I would argue that now is the time to make the code properly 64 bit
AB> clean before 64 bit becomes even more widespread. Stuff shouldn't
AB> accidentally break. Embedded apps will likely stick to an old
AB> distribution of net-snmp and desktop stuff that makes these assumptions
AB> most likely needs other fixes for 64 bit anyway.

But your problem is that you didn't use the correct data types right?
Or you're trying to translate data types from one application suite to
another? Did you actually find a spot in the code that isn't doing the
right thing internally? If so, where? Your code is breaking because
you're not using the APIs properly (I'd argue). That's because the
APIs don't have convenient datatypes, certainly! Since an oid node is
limited to 32 bits there is no reason to have a typedef using a u_long
but it doesn't technically break anything to do so. It's not just
architecturally clean.

I'm willing to consider (but not yet voting in favor of) doing a
Net-SNMP 6.0 with new datatypes for various things, but it warrants more
than just a simple patch to the existing code if we decide we want to
drop backwards compatibility that badly.

(for historical sake: this all dates back to very early releases of
CMU-SNMP which is what set the architecture in place and we've never
broken it)
--
Wes Hardaker
Sparta, Inc.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757...un.com/javaone
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders