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

Hello all, long time no see!

hardaker@users.sourceforge.net said:
> There is a *ton* of external code out there that is built using our
> package as a base platform, and if they're using u_long as the data
> type in their code any change we make will break that. And badly,
> since many times pointers are passed around (otherwise it would be
> a simple cast and wouldn't amount to much of a problem).

Note, the possibility for such breakage only exists on 64-bit platforms,
because on a 32-bit platform sizeof(u_long) = 4, i.e. there is no actual
change.

Further, one might equally put the argument that if user code is using
'unsigned int' as their data type, then *not* making the change will
mean their code will suddenly stop working on a 64-bit platform (when it
previously has been working fine on 32-bit platforms).

Why would anyone use 'unsigned int's? Well -- why would anyone use
'u_long's? The correct way to do it is to use 'oid', and any code written
like that will continue to work.


hardaker@users.sourceforge.net said:
> 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.

Backward compatibility is important -- but here you are striving to
guarantee backward compatibility for incorrectly-written code, which is
more than people can realistically expect.

The most significant problem with use of u_long on a 64-bit platform is
that the library only performs overflow checking in the ASN.1 parser. An
SNMP OID sub-identifier can never be more than (2^32)-1 so it should always
be an error to pass such an identifier to any function. Currently you can
pass in bad OIDs and nothing complains until (perhaps) some time later
you get a log message that something has been truncated. Cause and effect
are highly uncorrelated! If you consider the amount of checking code that
would need to be added to every function entrypoint to give a domain error
when a large u_long value was passed in -- well, I think it's unrealistic.

John


-------------------------------------------------------------------------
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