Looking for feedback on string APIs

The LSB spec seems to have picked up a variety of glibc-specific (not
in the Single Unix Spec) string functions.  We're wondering which of
the following people think we should keep.  Do you know of
applications using these?  Do you regard them as being useful enough
that an application should be able to get a system-supplied
implementation?

Replies can go to the bug (
http://bugs.linuxbase.org/show_bug.cgi?id=414 ) or to me and/or the
list by email.

stpcpy - more or less a replacement for strcat
__stpcpy - mangling of stpcpy
stpncpy - sort of a cross between of stpcpy and the strncpy family
  (strings which may or may not be \0 terminated).  Very awkward, e.g.
  char buffer[50];
  char *to = stpncpy(buffer, 50);
  to = stpncpy(to, 50 - (buffer - to));
strcasestr - case-insensitive search.  Seems potentially useful.
strfry - would seem to be a joke API, chosen just for the name.
strndup - \0 terminates the result no matter what, so could be useful.
strnlen - seems like a one-liner on top of memchr.  Perhaps more robust
  than strlen (what if the \0 is supposed to there but is missing due
  to a bug elsewhere?)
strsep - like strtok but treats multiple delimiters as meaning an
  empty token.  Writes into the supplied string but doesn't have the
  other reentrancy problems that strtok does.
strtok_r - Fixes reentrancy problems with strtok but still writes into
  the supplied string.  As with strsep, the alternative to writing
  into the string is presumably a loop which calls strspn.
__strtok_r - goes with strtok_r
strverscmp - Doesn't seem to match, say, the RPM version ordering.
  Perhaps useful in getting foo8, foo9, foo10, etc to sort in numeric
  order without resorting to foo08, foo09, foo10, etc.

-- 
Jim Kingdon
Free Standards Group