OK, my five cents : I feel the best is "come to some quick concensus on what a proper directory hierarchy for snmplib might be, and put old & new little files in a subdir." However, guts feeling says this concensus will not be reached quickly...
Therefore I think the only reasonable for now is "add new file strtok_r.c (seems to be the previous pattern)" Keeping it separate makes it easier to check for updates of these files (which sometimes come other projects). So my argument is one of maintainance and easier tracking (cvs log) for just a particular helper function. Once these small files are moved into a separate subdir, the argument of having multiple files will be a non-issue. -- Geert -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Story (Coders) Sent: Wednesday, October 06, 2004 3:22 PM To: Dave Shield Cc: [EMAIL PROTECTED] Subject: Re: proposal: snmplib/string_utils.c On Wed, 06 Oct 2004 09:44:01 +0100 Dave wrote: DS> > If people don't like combining them, how about at least putting DS> > them in a sub-directory? DS> DS> I have long been advocating a more structured approach to the DS> library. But I don't think now is the right time to start doing DS> this. Ok, in the meantime, where do you suggest would be a good file to put this new function? tools.c? DS> We're meant to be concentrating on getting 5.2 out of the door. This is part of getting 5.2 out the door. Moving to consistent use of strtok_r is a bugfix, and we need to put an implementation in the lib for platforms that don't have it. DS> I'd rather wait a while and look at restructuring the library DS> *properly*, with a clear overall design model, rather than tackling DS> it piecemeal. Well that's great if you expect to have the time to do it properly. I don't foresee that in the near future, so I subscribe to the 'every little bit helps' philosophy. So the current choices are: 1) add strtok_r to tool.c as a temporary location 2) add new file strtok_r.c (seems to be the previous pattern) 3) add a new file string_utils.c, merging in existing str*.c files 4) come to some quick concensus on what a proper directory hierarchy for snmplib might be, and put old & new little files in a subdir. I vote for 3, as I don't like one-function files, and I think astring_utils.c would be a good idea for a proper library restructure anyways. My second choice would be 2. -- Robert Story; NET-SNMP Junkie <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp> Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders> You are lost in a twisty maze of little standards, all different. ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
