[lsb-discuss] Looking for feedback on string APIs
mhatle at mvista.com
Fri Nov 5 10:01:41 PST 2004
I'm replying just based on my experience working with many open source
applications and attempting to port them from platform to platform. I
don't believe any of the items below are "hard" to provide locally in an
application.. but many are certainly used and very useful.
Jim Kingdon wrote:
> 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 buffer;
> char *to = stpncpy(buffer, 50);
> to = stpncpy(to, 50 - (buffer - to));
The above is used extensivly in a number of applications (our internal
ones) as well as programs like RPM.
> strcasestr - case-insensitive search. Seems potentially useful.
I've seen it used in numerous applications, unfortunatly my memory is
failing me as to which ones.
> strfry - would seem to be a joke API, chosen just for the name.
I don't know of any uses of that.
> strndup - \0 terminates the result no matter what, so could be useful.
This one is used pretty regularly in my experience. (Especially as a
bounded replacement to strdup of course.)
> 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?)
strnlen is used fairly extensivly in my experience.
> 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
I've seen the above used, but I don't know how often they are used.
> 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.
Never run across that one before.
MontaVista Software, Inc.
More information about the lsb-discuss