Edward Pilatowicz wrote: > On Tue, Jan 13, 2009 at 10:43:58PM +0100, Darren Reed wrote: > >> Edward Pilatowicz wrote: >> >>> On Tue, Jan 13, 2009 at 02:07:57PM +0100, Darren Reed wrote: >>> >>> >>>> Christopher Horne wrote: >>>> >>>> >>>>> .... >>>>> These functions will be documented in a new man page, >>>>> string(9F). For consistency with string(3C), the new >>>>> string(9F) man page will also subsume contents of strchr(9F), >>>>> strcmp(9F), strspn(9F), and strlen(9F). >>>>> >>>>> >>>>> >>>> Is there any particular reason why we aren't going to whole >>>> way here and documenting the same functions on string(9F) >>>> as we do with string(3C)? (i.e. why does strcpy(9f) need >>>> to be separate, or did that just get missed in the writing of >>>> this email?) >>>> >>>> >>>> >>> i'm preparing a large putback that was going to introduce multiple >>> private versions of strcpy() and strfree(). one of my code reviewers >>> pointed out that this seemed suboptimal, and i agreed. hence this case. >>> >>> by all means, you should feel free to determine if there are any more >>> string(3C) interfaces missing from the ddi and add them yourself, but i >>> didn't make that a part of this case. >>> >>> >> It's more that I was curious if there was enough synergy with >> what you're doing and what exists to provide a more consistent >> feel to the documentation between sections 3C and 9F - not to >> add new interfaces to the ddi. e.g. strcpy(3c), etc, all point to >> string(3c), so why should strcpy(9f) need to be independat to >> string(9f)? >> >> > > in my proposal, i was hoping to provide a consistent feel between > string(3c) and string(9f). > > i was planning to document strcpy() in string(9f), and then strcpy(9f) > would be a link to string(9f). string(9f) would also subsume the > strchr(9F), strcmp(9F), strspn(9F), and strlen(9F) man pages, which > would also become links to string(9f). > > there would be no independant version of strcpy(9f). > > does that clarify things? >
That's exactly what I was hoping for, thanks. Cheers, Darren
