[I'm glad this thread is finally getting attention; it's an important one]
History:
- oid has always been typecast since the dawn of time as a u_long
- in fact, almost every int in our system is typecast as u_long,
dating back to the original CMU code. This includes 32 bit SNMP
integers, which are required to be returned through the API as longs.
- in fact, we (starting in UCD-SNMP) added a bunch of typedefs
*to their original types* to make things more clear and provide
type safety and compiler-checks. But the important thing here is
that anytime there is 3rd-party code out there that might be using
a u_long where they should be using a netsnmp_foo_t we've tried to
never change the underlying type. Because it means a non-easy
upgrade path. And we already have huge huge huge issues getting
people to upgrade. Heck, we still occasionally see questions
regarding the 4.x line of code.
- You can't say "this architecture" or "that architecture" will break
or work, because sizes could be any of:
| | choice 1 | choice 2 |
|---------------+----------+----------|
| unsigned int | 32 | 64 |
| unsigned long | 32 | 64 |
The two most common choices are:
- int = 32, long = 32
- int = 32, long = 64
However, other combinations are not prohibited by C itself.
- Net-SNMP works on many many many many architectures. Stating that
"everyone should be using 64 bit longs these days" isn't a valid
argument.
- Net-SNMP is distributed with many OSes. Arguing that if we don't
do X, it'll break OS Y doesn't hold much water unless we've taken
accurate stock that Y is the *only* one that will break/work. We
have to think about the whole, not a part.
- Therefore, any solution must work on all of the above.
- Ideally, if we want to keep our backwards compatibility intact,
well... I'll leave this as an exercise
So, the only options going forward:
1) Leave oid typedefed to u_int32 going forward from 5.6.1
+ Pro: it's the proper sizing according to the SNMP type
+ Con: it'll almost certainly break existing code that is using a
local u_long[] array somewhere and expecting the types to match.
Sub choice:
A) produce 5.6.1.1 and bump the so number?
B) bump it in 5.6.2?
C) give up and don't bump it
2) Change the u_int32 back to u_long, and *fix the broken code*.
(IE, If printing doesn't work that can be fixed)
+ Pro: it's the most backwards compatible and won't break anyone
anywhere and will fix our code's bugs.
+ Con: It still keeps us in the dark ages, good or bad, of C
types that don't match the data types. But this isn't the only
one either.
Sub choice:
A) produce 5.6.1.1 immediately
B) wait for 5.6.2
This choice needs to be made not based on Fedora, etc, but on what is
the right thing to do given the above criteria. Both sides have pros
and cons, and I have *no doubt* that some people think one pro/con is
better than another pro/con. The question is, what do most people think
is the right decision? #1 or #2?
[on a side note, I have nothing against Fedora; the above makes me think
I don't care about them, which couldn't be further from the truth.
Fedora is the OS I live on for almost all my machines, and I'm a
maintainer of large number of fedora packages; but I can't be biased
myself and need to think about the bigger picture, not just one OS]
--
Wes Hardaker
Please mail all replies to net-snmp-coders@lists.sourceforge.net
------------------------------------------------------------------------------
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
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
