On 05/04/2011 11:34 PM, Wes Hardaker wrote:
> RJA> Can someone explain the rationalization of changing oid definition
> RJA> from a long to a 32bit integer in net-snmp 5.6.1?
>
> Well, a couple of points:
>
> 1) an OID actually is limited to 32 bits, so the newer type makes some
>    sense.
Is way more clear that way. A "long" could have more than 32 bits
(infact in snmp_client.c, function snmp_set_var_value there are some
nice conditional compiling based on integer type size). IMHO integral
types in C are confusing the way they are...

> 2) That being said, it was changed in r17809 with the following log from
>    magfr:
>
>    "Change oid to be a 32-bit type on ILP64 and LP64 platforms."
In which platforms, IIRC, integer (int) and long are 64bits long. Thus
using u_long as an alias to oid would lead on these platforms to 64 bits
object identifier, which is _wrong_. Putting

typedef uint32_t oid;

will give the "right" results on every platform

> 3) All that being said, I'm not sure it was right to change it either.
>    I'd support a patch to revert it to a u_long for 5.6.2 and other
>    future releases as well
> But I'd like to hear what Magnus has to say first about the reasoning
> for breaking backwards compatibility...
Contrary to what you and other posters seem to think, *this will
introduce no binary incompatibility* except on platform where u_long
wasn't 32 bits long. For those like the aformentioned ILP64 platforms
where u_long is _more_ than 32 bits this will actually correct a
problem. I'm not aware of platforms where long is shorter than 32 bits
(and IIRC this could non be). For "normal" platforms, where a long _is_
a 32 bits integer then both typedefs lead to exactly the same binary output.

-- 
Leo Cacciari
Aliae nationes servitutem pati possunt populi romani est propria libertas


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

Reply via email to