>>>>> On Tue, 15 Apr 2008 16:41:01 +0100, Alex Bennee <[EMAIL PROTECTED]> 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;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
