On Sat, 2005-10-01 at 11:38 -0700, rwilcox wrote: > --- Robert Story <[EMAIL PROTECTED]> wrote:
> > Knowing full well that it is a waste of my time to > > do so, I proposed a mega search/replace of all ints > > and longs with the new int32_t, with cleanup for > > int64_t where needed. > > > > I am all in favor of making this modification. Is > there a process in place to enact change of this > magnitude? The reason that Robert phrased his response in the way that he did, is that he knows things aren't quite as simple as that. Replacing all int/long declarations with suitable int32_t/int64_t (or unsigned equivalents) would be a tedious but fairly straightforward process. The difficulty is that it would blow a massive hole in the principle of backward compatability. *All* existing programs that use the Net-SNMP libraries would need to be changed to match, and that's not a step we could undertake lightly. It's something that we're going to need to address eventually, but would probably require a completely new top-number release (i.e. Net-SNMP 6.x). And there are several other significant changes that should probably be tackled as part of this move. That doesn't meant that nothing can be done in the meantime. It would be perfectly possible to clean up any *internal* declarations within library or agent routines. Or annotate each public API with the relevant types that ought to be used. Actually changing the public API calls would need to wait, but patches along these lines should be safe enough. Dave ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
