I personally would vote for option 3. Keeping string mangling utility funcions together in one file feels like ever elusive "Right Thing To Do" IMO.
Andy
Dave Shield wrote:
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'd order those as:
2, 3, 1, 4 + - (with the amount of space indicating approximate strength of preference).
Robert> I vote for 3, as I don't like one-function files, and I think Robert> a string_utils.c would be a good idea for a proper library Robert> restructure anyways. My second choice would be 2.
I'd be perfectly happy with either of those. Separate files is probably slightly more flexible - I seem to remember running into problems when a particular configuration needed to link with some of our utility functions, but not all.
Consider an embedded agent within an application that implemented it's own version of strtok but not strtok_r on an architecure that didn't have either of them natice. If both of these routines are defined in the same code file, you'd end up with a name clash.
That's perhaps relatively unlikely, and if we're not bothered about the prospect, then I'd agree that 'string_utils.c' would be a good idea.
Dave> I'd rather wait a while and look at restructuring the library *properly*,
Dave> with a clear overall design model, rather than tackling it piecemeal.
Robert> Well that's great if you expect to have the time to do it properly.
Robert> I don't foresee that in the near future, so I subscribe to the
Robert> 'every little bit helps' philosophy.
That's OK if we've got an existing agreed framework to work within.
I don't believe that is the case here.
I've got a general recollection of trying to stimulate some discussion
about such a framework during the Great Library Fiasco, and getting
nowhere fast. I would be more than slightly miffed if we embarked
upon such a discussion now, at the busiest time of my year, and with
a release deadline looming over us.
Using a deadline to concentrate the mind is one thing, but rushing this seems Just Plain Daft. I would argue *very* strongly against trying to agree on such a structure in a hurry, when we don't need to.
Dave
------------------------------------------------------- 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
