[lsb-discuss] Looking for feedback on string APIs
kingdon at freestandards.org
Fri Nov 5 09:50:13 PST 2004
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
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 *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.
Free Standards Group
More information about the lsb-discuss