Vladimir Kotal writes:
> James Carlson wrote:
> > I'm not sure I'd recommend strspn/strcspn specifically.  Aren't there
> > other tools available?
> 
> I added the str{,c}spn sentences just to satisfy a comment in CR 6487100 
> which suggests to use these instead of strsep() in "internal code" (this 
> most probably means ON) and having strsep() only as a compatibility tool.

Yes, that seems to refer to the internal coding practices.  What
others might do or want to do is probably on their heads.  ;-}

> Side blurb^Wnote: it seems to me that while this (or any other) man page 
> should inform the users about potential traps it should not serve as 
> fostering tool but instead offer the variety of APIs and let the 
> communities to do the rest.

Where there are cases that we know about significant API defects
(gets(3C) is the poster boy for "defective interfaces"), I think it's
good to warn people away, and we probably even have an obligation to
do so.  If there are cases that we think are marginal, I don't think
it's a bad idea to have advice directing users to look at some
alternatives -- just a "see also ..." will do.

I think you're right that we don't have much reason to insist on
things that are a matter of style.  There are those who routinely
write to strings while parsing them, and think nothing of it.  There
are others who'll drive many miles out of the way to avoid it -- even
allocating a new temporary and using that instead.

"How to write a good utility routine" sounds like a chapter for your
next "Designing APIs" book, and not part of a man page.  ;-}

> +     first argument. These functions do not check for        overflow 
> +     of  the array pointed to by the first argument.

That sentence looks out of place; it's referring way back to strcpy
and strcat alone -- not strtok or strsep.  Not your problem, but the
man page could use a little wordsmithing.

The rest looks good to me.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Reply via email to