DS> The difficulty is that it would blow a massive hole in DS> the principle of backward compatability. *All* DS> existing programs that use the Net-SNMP libraries DS> would need to be changed to match
> I don't think that's true. The compiler generally accepts differently > named types so long as they resolve to the same size and sign-ed-ness. > I think the impact would be much less that you think. Hmmmm... possibly. I'm not sure. Perhaps when the chaos of the 5.2.2 and 5.3 releases has died down, we could return to this again. DS> That doesn't meant that nothing can be done in the DS> meantime. It would be perfectly possible to clean up DS> any *internal* declarations within library or agent DS> routines. > Heh. All we need is a nice list of internal vs public API routines. Grrrr!!!!! In case you don't remember, I was in the middle of doing exactly that as part of the the Great Library Fiasco, when I had things pulled from under my feet. I would thank you not to remind me of such dark days! I'll also point out that I didn't say "internal API routines". I said "internal declarations" - i.e. the local variables *within* a routine. Those could safely be changed without touching any of the visible APIs - whether nominally internal or public. Doing that would be a sensible (and fairly safe) starting point for deciding exactly what the API prototypes should be. 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
