This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: strrstr
- From: Reuben Thomas <rrt at sc3d dot org>
- To: Carlos O'Donell <carlos at systemhalted dot org>
- Cc: libc-help at sourceware dot org
- Date: Fri, 2 May 2008 15:00:06 +0100 (BST)
- Subject: Re: strrstr
- Dkim-signature: a=rsa-sha1; t=1209736804; x=1210341604; s=key1024; d=sc3d.org; c=relaxed/relaxed; q=dns; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=HMtSJDEOPZ+j6kqdC7KzY9R8NdFNflgYVNfBdG+G1jrmc2ei01UxU1yupgtFLC587WBfuSb9iY028hZ0q6zbhmnEEh+ZOUqGlr7UBt+UV/0Uuy/cd8AnqsTI8/bnry9eDl/CMjSpcs/okbak/vzE88B0FAlDURnwzEgDbiNz17k=
- References: <alpine.DEB.1.00.0804302028360.19137@canta> <20080430204909.D4E8926FA04@magilla.localdomain> <alpine.DEB.1.00.0804302245270.6734@canta> <119aab440805020622g7a8c77d6v45c157429059557d@mail.gmail.com>
On Fri, 2 May 2008, Carlos O'Donell wrote:
On Wed, Apr 30, 2008 at 6:10 PM, Reuben Thomas <rrt@sc3d.org> wrote:
It fills an obvious gap in the API (strchr, strrchr; strstr, strrstr), and
has the same semantics and name pretty much everywhere, so there's no
contention to resolve in what it should be called or do.
I'm CC'ing libc-help in order to continue this dicussion.
If you are really interested in adding reverse search variants to the
API you will need to do a little leg work.
I'm only interested in adding this one function.
1. What other C libraries implement these functions?
The only one I can find is HP-UX's libc, as I said; the other
implementations I found were in applications. (I presume by "C library" you
mean "libc", not "library implemented in C".)
I don't have access to development resources for any proprietary operating
systems at the moment, other than what I can find on the web, so I can't
make an exhaustive survey.
2. How does relying on these functions effect portability between OSs?
I assume you mean "if an application programmer relies on the existence of
this function, how does it affect portability between OSs?" Obviously, a
program that assumes the existence of this function would not work on the
many OSs that do not support it. Hopefully one day many more OSs will;
indeed, if only two libc's were to adopt it, glibc and BSD's libc, then it
within a few years a large proportion of programs would be able to rely on
its existence on modern systems. However, for the forseeable future I'd
envisage not relying on it, but, as I do at present in my programs that use
it, testing for the existence of the function and supplying an
implementation in ISO C in case it does not exist.
3. Are all the strrstr's the same?
So far, I've only looked at the name and prototypes.
Do you have a test suite which shows they are the same?
No, I don't. I agree that writing a test suite is a good idea. I'll look at
the glibc sources to see how this is done for other functions.
Since strrstr is to strstr as strrchr is to strchr, there's not much room
for variation in spec.
4. Does your strrstr support all the new character types being proposed by
TR 19769 for the C standard?
Yes: variants for different character types can be obtained by replacing
"char" in strrstr's definition by another fixed-width character type, and
the call to strlen with a call to an appropriate function for the given
type.
Here's a suggested definition, based on the info documentation for similar
functions (specifically, strrchr and strstr):
-- Function: char * strrstr (const char *HAYSTACK, const char *NEEDLE)
The function `strrstr' is like `strstr', except that it searches
backwards from the end of the string HAYSTACK (instead of forwards
from the front).
For example,
strrstr ("hello, world", "l")
=> "ld"
strrstr ("hello, world", "wo")
=> "world"
--
http://rrt.sc3d.org/ | partisan, n. an adherent without sense (Bierce)