Hello all, long time no see! [EMAIL PROTECTED] 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. [EMAIL PROTECTED] 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;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
