On Thu, Jun 24, 2010 at 10:06:05AM +0100, Dave Shield wrote: > On 23 June 2010 21:11, Magnus Fromreide <ma...@lysator.liu.se> wrote: > > I think r17794 fixed this issue. > > As far as I can tell, revision 17794 is purely concerned with how > ranges are *displayed* as part of dumping MIB structures.
Correct. > [Removed stuff that I can look at after the weekend] > > Two comments. > Firstly, I would regard 'range_list' as an internal data structure, > rather than part of the public API, so it would be legitimate (IMO) > to tweak this as part of a new major release. I agree with this but think we should remove the struct from the public header in that case. > Hence it might be possible to make such a change for 5.6 (if we move fast) > > However, would this actually help? On 32-bit systems, 'long' and 'int' are > typically both 32 bits, so suffer from exactly the same issues. > The problem (as I see it) is one of signed vs unsigned, rather than 32 > vs 64 bit. I agree here. > I suspect that what is probably needed is some form of flag within the > range_list structure, to indicate whether the values should be treated as > signed or unsigned (with appropriate casts if necessary). There already is a flag. Not in the range_list structure but in the associated type declaration. It is named 'type'. /MF ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
