Re: Looking for feedback on string APIs

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
> 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));

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.

Mark Hatle
MontaVista Software, Inc.