>>>>> On Wed, 11 May 2011 10:56:58 -0400, Doug Manley <[email protected]> >>>>> said:
DM> If we take a page from POSIX's book, we could typedef everything to be DM> magical net-snmp types so that the underlying implementation is not DM> important as long as everyone recompiles his code when a new version DM> comes out. But there in lies the rub. We know for a fact that long ago, a lot of external code was written that does things like: static u_long foo; return &foo; for example, assuming that at the time a u_long was the right datatype to return. I would not be surprised at all if something like the following was done somewhere too (in fact, I'm quite sure it has been, but I'm not 100% sure that the code is still in use): static u_long myoid[128]; myoid[0] = 1; myoid[1] = 3; /* ... */ return &myoid; Now, with the change that has been made converting the oid typedef from u_long (which worked with the above 3rd-party code) to u_int32, we'll actually cause the 3rd-party code to fail. It's *not* just a recompile for them. And what's worse, we know from experience that network management code is less maintained than most other code. Companies frequently just barely get NM code working and then go off to implement new routing tricks instead of doing a decent job maintaining their NM code. Because that's where the money is. Unfortunately. Now... Again, I'm declaring the *why* it's a potential problem. I'm not indicating my side of the opinion (yet). Now, if we have APIs that work with OIDs as u_longs then nothing goes wrong *unless* we run into overflows. Many of our APIs (which derive from the CMU days, where much less was typedefed in the first place) all support many cases where the data is expected to be in 4 bytes but the C-type is actually 8 bytes long. The Net-SNMP OID APIs *MUST* be safe about this, because lots of people build in embedded environments where all is not equal (I vaguely recall a long time ago some weird implementation that something as a short instead of even an int; but I don't remember the details). So, regardless of whether or not we re-typedef, we need to: 1) write some unit-tests that test the APIs under multiple circumstances. 2) Make these unit tests pass for the *old* code branches (IE, the APIs must work when an oid is typedefed to u_long) 3) Make these unit tests pass for the *new* code branches (IE, the APIs must work when an oid is typedefed to u_int if/when we decide it's the right thing to do) DM> My vote is for change; if we try to be backward compatible with all DM> code ever written against the library, then nothing will ever get DM> done. If we don't, nothing will every get upgraded. The biggest problems with this long-term maintenance of this package stem from a few things: 1) The above "NM code isn't updated" problem. 2) Getting people to believe that it's safe to have their intern upgrade the NM code to the latest and greatest upstream Net-SNMP release has been historically very hard to do. The only way that we've achieved it at all is because we *are* so backward compatible and we've reiterated over and over that very old mib code should continue to work. If we change this policy, it's a much bigger decision than just this one type change and will likely affect contributions given to the project for the long distant future. It's very easy to write software that only depends on itself, and has no one depending on it. It's very hard to write software that encourages long-term API stability when many many people depend on it. Remember, this whole problem got flagged because someone wondered why the change was made in the 5.6.1 line. That someone has been quiet since then, but obviously someone noticed because it likely broke something. The fact we got a question at all indicates it affected someone negatively. -- Wes Hardaker Please mail all replies to [email protected] ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
