On Tue, 2008-04-15 at 08:15 -0700, Wes Hardaker wrote:
> >>>>> On Mon, 14 Apr 2008 13:57:35 +0100, "Alex Bennee" <[EMAIL PROTECTED]> 
> >>>>> said:
> 
> AB> + typedef uint32_t oid;
> 
> vs
> 
> AB> + typedef u_long  oid;
> 
> 
> There are a number of places that could benefit from a switch to a true
> int32.  OIDs are only one such place (standard Integer or Integer32
> datatypes being another).  However, we can't make changes like that.
> 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).

Well of course the reason I had to make the change is our platform uses
both libsmi and net-snmp which on 64 bit had a different idea of how big
a object subid could be, when neither could contain more than a 32bit
value.

Besides if external code is using u_long as it's base type I'm tempted
to say they deserve what they get. Casting still works for pointer types
and warnings when:

        oid snmp_oid_array[10]={1,2,3,4,5,6,7,8,9,10};
        u_long *ptr_to_array = &snmp_oid_array[0];

gives:

oid_size_warning.c:8: warning: initialization from incompatible pointer
type

It should be a big enough clue.

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

I would argue that now is the time to make the code properly 64 bit
clean before 64 bit becomes even more widespread. Stuff shouldn't
accidentally break. Embedded apps will likely stick to an old
distribution of net-snmp and desktop stuff that makes these assumptions
most likely needs other fixes for 64 bit anyway.

-- 
Alex Bennee, Software Engineer
I want to see people using Perl to glue things together creatively, not
just technically but also socially. -- Larry Wall in
<[EMAIL PROTECTED]>


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

Reply via email to