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? >>> For completeness, can a draft copy of the proposed >>> string(9F) please be placed in the case directory? >>> >>> >> >> given how trivial these interfaces are, i'd prefer not to. i believe >> the current proposal compleatly documents the semantics of the new >> interfaces i'm introducing. (hence adding man pages would just be >> adding noise to this case.) if your confused about how these interfaces >> will behave then please ask more specific questions and i can improved >> the case material. if you're just interested in reviewing the final man >> pages i can add you on the interest list of the man page bug i'll be >> filing. hopefully your ok with this... >> > > I think adding me to the interest list for the bug would be fine. > > I'm perfectly happy with the architecture (so please don't count > me as dissenting), I think this is just something for the docs folks > to think about after. > cool. i'll be sure to add you to the interest list. ed
