1997-08-21 18:57:35 -04:00
|
|
|
/* Simple implementation of strstr for systems without it.
|
|
|
|
This function is in the public domain. */
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
configure.in (MAKEINFO, PERL): Detect these.
* configure.in (MAKEINFO, PERL): Detect these.
(--enable-maintainer-mode): Add.
* configure: Regenerate.
* Makefile.in (MAKEINFO, PERL): Define.
(libiberty.info, libiberty.dvi, libiberty.html): New.
(CFILES): Add bsearch.c.
(CONFIGURED_OFILES): New, list of objects configure might add.
(maint-missing, maint-buildall): New, for maintainers only.
(clean, mostlyclean): Add info/dvi/html files.
* libiberty.texi, copying-lib.texi, obstacks.texi, functions.texi: New.
* gather-docs: New, for maintainers.
* maint-tool: New, for maintainers.
* alloca.c, atexit.c, basename.c, bcmp.c, bcopy.c, bsearch.c,
bzero.c, calloc.c, clock.c, configure.in, configure, getcwd.c,
getpagesize.c, getpwd.c, index.c, memchr.c, memcmp.c, memcpy.c,
memmove.c, memset.c, putenv.c, rename.c, rindex.c, setenv.c,
sigsetmask.c, strcasecmp.c, strchr.c, strdup.c, strerror.c,
strncasecmp.c, strncmp.c, strrchr.c, strstr.c, strtod.c, strtol.c,
tmpnam.c, vfork.c, vprintf.c, waitpid.c, xatexit.c, xexit.c,
xmalloc.c, xmemdup.c, xstrdup.c, xstrerror.c: Add or update
documentation.
Co-Authored-By: Phil Edwards <pedwards@disaster.jaj.com>
From-SVN: r45828
2001-09-26 14:16:17 -04:00
|
|
|
@deftypefn Supplemental char* strstr (const char *@var{string}, const char *@var{sub})
|
1997-08-21 18:57:35 -04:00
|
|
|
|
configure.in (MAKEINFO, PERL): Detect these.
* configure.in (MAKEINFO, PERL): Detect these.
(--enable-maintainer-mode): Add.
* configure: Regenerate.
* Makefile.in (MAKEINFO, PERL): Define.
(libiberty.info, libiberty.dvi, libiberty.html): New.
(CFILES): Add bsearch.c.
(CONFIGURED_OFILES): New, list of objects configure might add.
(maint-missing, maint-buildall): New, for maintainers only.
(clean, mostlyclean): Add info/dvi/html files.
* libiberty.texi, copying-lib.texi, obstacks.texi, functions.texi: New.
* gather-docs: New, for maintainers.
* maint-tool: New, for maintainers.
* alloca.c, atexit.c, basename.c, bcmp.c, bcopy.c, bsearch.c,
bzero.c, calloc.c, clock.c, configure.in, configure, getcwd.c,
getpagesize.c, getpwd.c, index.c, memchr.c, memcmp.c, memcpy.c,
memmove.c, memset.c, putenv.c, rename.c, rindex.c, setenv.c,
sigsetmask.c, strcasecmp.c, strchr.c, strdup.c, strerror.c,
strncasecmp.c, strncmp.c, strrchr.c, strstr.c, strtod.c, strtol.c,
tmpnam.c, vfork.c, vprintf.c, waitpid.c, xatexit.c, xexit.c,
xmalloc.c, xmemdup.c, xstrdup.c, xstrerror.c: Add or update
documentation.
Co-Authored-By: Phil Edwards <pedwards@disaster.jaj.com>
From-SVN: r45828
2001-09-26 14:16:17 -04:00
|
|
|
This function searches for the substring @var{sub} in the string
|
libiberty.texi: (Top level): Add syncodeindex pg.
* libiberty.texi: (Top level): Add syncodeindex pg. Add
@dircategory and @direntry directives. Add @finalout.
(many nodes): Lose the next,prev,up pointers on the @nide line.
(Using, Supplemental Functions, Replacement Functions): Fix
markup.
(Functions): Move around, to allow makeinfo to build the manual
without next,prev,up pointers in thye node lines.
(Licenses): Fix typos.
* index.c, rindex.c, strchr.c, strerror.c, strrchr.c, strstr.c,
strtol.c, xatexit.c, xexit.c, xmalloc.c: Fix spelling and markup.
* functions.texi: Regenerate.
* copying-lib.texi: Lose the next,prev,up pointers on the @node
line.
From-SVN: r45847
2001-09-27 21:55:37 +02:00
|
|
|
@var{string}, not including the terminating null characters. A pointer
|
alloca.c, [...]: Improve manual formatting.
* alloca.c, clock.c, getcwd.c, getpagesize.c, getpwd.c, index.c,
libiberty.texi, memchr.c, putenv.c, rindex.c, strchr.c, strdup.c,
strerror.c, strrchr.c, strstr.c, strtod.c, tmpnam.c, vfork.c,
xatexit.c, xmalloc.c, xstrerror.c: Improve manual formatting. Fix
spelling. Give names to function arguments in documentation. Use
(void) prototypes in documentation.
* functions.texi: Regenerate.
From-SVN: r46068
2001-10-07 22:53:31 +01:00
|
|
|
to the first occurrence of @var{sub} is returned, or @code{NULL} if the
|
configure.in (MAKEINFO, PERL): Detect these.
* configure.in (MAKEINFO, PERL): Detect these.
(--enable-maintainer-mode): Add.
* configure: Regenerate.
* Makefile.in (MAKEINFO, PERL): Define.
(libiberty.info, libiberty.dvi, libiberty.html): New.
(CFILES): Add bsearch.c.
(CONFIGURED_OFILES): New, list of objects configure might add.
(maint-missing, maint-buildall): New, for maintainers only.
(clean, mostlyclean): Add info/dvi/html files.
* libiberty.texi, copying-lib.texi, obstacks.texi, functions.texi: New.
* gather-docs: New, for maintainers.
* maint-tool: New, for maintainers.
* alloca.c, atexit.c, basename.c, bcmp.c, bcopy.c, bsearch.c,
bzero.c, calloc.c, clock.c, configure.in, configure, getcwd.c,
getpagesize.c, getpwd.c, index.c, memchr.c, memcmp.c, memcpy.c,
memmove.c, memset.c, putenv.c, rename.c, rindex.c, setenv.c,
sigsetmask.c, strcasecmp.c, strchr.c, strdup.c, strerror.c,
strncasecmp.c, strncmp.c, strrchr.c, strstr.c, strtod.c, strtol.c,
tmpnam.c, vfork.c, vprintf.c, waitpid.c, xatexit.c, xexit.c,
xmalloc.c, xmemdup.c, xstrdup.c, xstrerror.c: Add or update
documentation.
Co-Authored-By: Phil Edwards <pedwards@disaster.jaj.com>
From-SVN: r45828
2001-09-26 14:16:17 -04:00
|
|
|
substring is absent. If @var{sub} points to a string with zero
|
|
|
|
length, the function returns @var{string}.
|
1997-08-21 18:57:35 -04:00
|
|
|
|
configure.in (MAKEINFO, PERL): Detect these.
* configure.in (MAKEINFO, PERL): Detect these.
(--enable-maintainer-mode): Add.
* configure: Regenerate.
* Makefile.in (MAKEINFO, PERL): Define.
(libiberty.info, libiberty.dvi, libiberty.html): New.
(CFILES): Add bsearch.c.
(CONFIGURED_OFILES): New, list of objects configure might add.
(maint-missing, maint-buildall): New, for maintainers only.
(clean, mostlyclean): Add info/dvi/html files.
* libiberty.texi, copying-lib.texi, obstacks.texi, functions.texi: New.
* gather-docs: New, for maintainers.
* maint-tool: New, for maintainers.
* alloca.c, atexit.c, basename.c, bcmp.c, bcopy.c, bsearch.c,
bzero.c, calloc.c, clock.c, configure.in, configure, getcwd.c,
getpagesize.c, getpwd.c, index.c, memchr.c, memcmp.c, memcpy.c,
memmove.c, memset.c, putenv.c, rename.c, rindex.c, setenv.c,
sigsetmask.c, strcasecmp.c, strchr.c, strdup.c, strerror.c,
strncasecmp.c, strncmp.c, strrchr.c, strstr.c, strtod.c, strtol.c,
tmpnam.c, vfork.c, vprintf.c, waitpid.c, xatexit.c, xexit.c,
xmalloc.c, xmemdup.c, xstrdup.c, xstrerror.c: Add or update
documentation.
Co-Authored-By: Phil Edwards <pedwards@disaster.jaj.com>
From-SVN: r45828
2001-09-26 14:16:17 -04:00
|
|
|
@end deftypefn
|
1997-08-21 18:57:35 -04:00
|
|
|
|
|
|
|
|
|
|
|
*/
|
|
|
|
|
2005-04-02 19:57:12 +00:00
|
|
|
#include <stddef.h>
|
|
|
|
|
libiberty: Make strstr.c in libiberty ANSI compliant
On Fri, Nov 13, 2020 at 11:53:43AM -0700, Jeff Law via Gcc-patches wrote:
>
> On 5/1/20 6:06 PM, Seija Kijin via Gcc-patches wrote:
> > The original code in libiberty says "FIXME" and then says it has not been
> > validated to be ANSI compliant. However, this patch changes the function to
> > match implementations that ARE compliant, and such code is in the public
> > domain.
> >
> > I ran the test results, and there are no test failures.
>
> Thanks. This seems to be the standard "simple" strstr implementation.
> There's significantly faster implementations available, but I doubt it's
> worth the effort as the version in this file only gets used if there is
> no system strstr.c.
Except that PR109306 says the new version is non-compliant and
is certainly slower than what we used to have. The only problem I see
on the old version (sure, it is not very fast version) is that for
strstr ("abcd", "") it returned "abcd"+4 rather than "abcd" because
strchr in that case changed p to point to the last character and then
strncmp returned 0.
The question reported in PR109306 is whether memcmp is required not to
access characters beyond the first difference or not.
For all of memcmp/strcmp/strncmp, C17 says:
"The sign of a nonzero value returned by the comparison functions memcmp, strcmp, and strncmp
is determined by the sign of the difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being compared."
but then in memcmp description says:
"The memcmp function compares the first n characters of the object pointed to by s1 to the first n
characters of the object pointed to by s2."
rather than something similar to strncmp wording:
"The strncmp function compares not more than n characters (characters that follow a null character
are not compared) from the array pointed to by s1 to the array pointed to by
s2."
So, while for strncmp it seems clearly well defined when there is zero
terminator before reaching the n, for memcmp it is unclear if say
int
memcmp (const void *s1, const void *s2, size_t n)
{
int ret = 0;
size_t i;
const unsigned char *p1 = (const unsigned char *) s1;
const unsigned char *p2 = (const unsigned char *) s2;
for (i = n; i; i--)
if (p1[i - 1] != p2[i - 1])
ret = p1[i - 1] < p2[i - 1] ? -1 : 1;
return ret;
}
wouldn't be valid implementation (one which always compares all characters
and just returns non-zero from the first one that differs).
So, shouldn't we just revert and handle the len == 0 case correctly?
I think almost nothing really uses it, but still, the old version
at least worked nicer with a fast strchr.
Could as well strncmp (p + 1, s2 + 1, len - 1) if that is preferred
because strchr already compared the first character.
2023-04-02 Jakub Jelinek <jakub@redhat.com>
PR other/109306
* strstr.c: Revert the 2020-11-13 changes.
(strstr): Return s1 if len is 0.
2023-04-02 20:05:31 +02:00
|
|
|
extern char *strchr (const char *, int);
|
|
|
|
extern int strncmp (const void *, const void *, size_t);
|
2005-04-02 19:57:12 +00:00
|
|
|
extern size_t strlen (const char *);
|
|
|
|
|
1997-08-21 18:57:35 -04:00
|
|
|
char *
|
2005-04-02 19:57:12 +00:00
|
|
|
strstr (const char *s1, const char *s2)
|
1997-08-21 18:57:35 -04:00
|
|
|
{
|
libiberty: Make strstr.c in libiberty ANSI compliant
On Fri, Nov 13, 2020 at 11:53:43AM -0700, Jeff Law via Gcc-patches wrote:
>
> On 5/1/20 6:06 PM, Seija Kijin via Gcc-patches wrote:
> > The original code in libiberty says "FIXME" and then says it has not been
> > validated to be ANSI compliant. However, this patch changes the function to
> > match implementations that ARE compliant, and such code is in the public
> > domain.
> >
> > I ran the test results, and there are no test failures.
>
> Thanks. This seems to be the standard "simple" strstr implementation.
> There's significantly faster implementations available, but I doubt it's
> worth the effort as the version in this file only gets used if there is
> no system strstr.c.
Except that PR109306 says the new version is non-compliant and
is certainly slower than what we used to have. The only problem I see
on the old version (sure, it is not very fast version) is that for
strstr ("abcd", "") it returned "abcd"+4 rather than "abcd" because
strchr in that case changed p to point to the last character and then
strncmp returned 0.
The question reported in PR109306 is whether memcmp is required not to
access characters beyond the first difference or not.
For all of memcmp/strcmp/strncmp, C17 says:
"The sign of a nonzero value returned by the comparison functions memcmp, strcmp, and strncmp
is determined by the sign of the difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being compared."
but then in memcmp description says:
"The memcmp function compares the first n characters of the object pointed to by s1 to the first n
characters of the object pointed to by s2."
rather than something similar to strncmp wording:
"The strncmp function compares not more than n characters (characters that follow a null character
are not compared) from the array pointed to by s1 to the array pointed to by
s2."
So, while for strncmp it seems clearly well defined when there is zero
terminator before reaching the n, for memcmp it is unclear if say
int
memcmp (const void *s1, const void *s2, size_t n)
{
int ret = 0;
size_t i;
const unsigned char *p1 = (const unsigned char *) s1;
const unsigned char *p2 = (const unsigned char *) s2;
for (i = n; i; i--)
if (p1[i - 1] != p2[i - 1])
ret = p1[i - 1] < p2[i - 1] ? -1 : 1;
return ret;
}
wouldn't be valid implementation (one which always compares all characters
and just returns non-zero from the first one that differs).
So, shouldn't we just revert and handle the len == 0 case correctly?
I think almost nothing really uses it, but still, the old version
at least worked nicer with a fast strchr.
Could as well strncmp (p + 1, s2 + 1, len - 1) if that is preferred
because strchr already compared the first character.
2023-04-02 Jakub Jelinek <jakub@redhat.com>
PR other/109306
* strstr.c: Revert the 2020-11-13 changes.
(strstr): Return s1 if len is 0.
2023-04-02 20:05:31 +02:00
|
|
|
const char *p = s1;
|
2005-04-02 19:57:12 +00:00
|
|
|
const size_t len = strlen (s2);
|
libiberty: Make strstr.c in libiberty ANSI compliant
On Fri, Nov 13, 2020 at 11:53:43AM -0700, Jeff Law via Gcc-patches wrote:
>
> On 5/1/20 6:06 PM, Seija Kijin via Gcc-patches wrote:
> > The original code in libiberty says "FIXME" and then says it has not been
> > validated to be ANSI compliant. However, this patch changes the function to
> > match implementations that ARE compliant, and such code is in the public
> > domain.
> >
> > I ran the test results, and there are no test failures.
>
> Thanks. This seems to be the standard "simple" strstr implementation.
> There's significantly faster implementations available, but I doubt it's
> worth the effort as the version in this file only gets used if there is
> no system strstr.c.
Except that PR109306 says the new version is non-compliant and
is certainly slower than what we used to have. The only problem I see
on the old version (sure, it is not very fast version) is that for
strstr ("abcd", "") it returned "abcd"+4 rather than "abcd" because
strchr in that case changed p to point to the last character and then
strncmp returned 0.
The question reported in PR109306 is whether memcmp is required not to
access characters beyond the first difference or not.
For all of memcmp/strcmp/strncmp, C17 says:
"The sign of a nonzero value returned by the comparison functions memcmp, strcmp, and strncmp
is determined by the sign of the difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being compared."
but then in memcmp description says:
"The memcmp function compares the first n characters of the object pointed to by s1 to the first n
characters of the object pointed to by s2."
rather than something similar to strncmp wording:
"The strncmp function compares not more than n characters (characters that follow a null character
are not compared) from the array pointed to by s1 to the array pointed to by
s2."
So, while for strncmp it seems clearly well defined when there is zero
terminator before reaching the n, for memcmp it is unclear if say
int
memcmp (const void *s1, const void *s2, size_t n)
{
int ret = 0;
size_t i;
const unsigned char *p1 = (const unsigned char *) s1;
const unsigned char *p2 = (const unsigned char *) s2;
for (i = n; i; i--)
if (p1[i - 1] != p2[i - 1])
ret = p1[i - 1] < p2[i - 1] ? -1 : 1;
return ret;
}
wouldn't be valid implementation (one which always compares all characters
and just returns non-zero from the first one that differs).
So, shouldn't we just revert and handle the len == 0 case correctly?
I think almost nothing really uses it, but still, the old version
at least worked nicer with a fast strchr.
Could as well strncmp (p + 1, s2 + 1, len - 1) if that is preferred
because strchr already compared the first character.
2023-04-02 Jakub Jelinek <jakub@redhat.com>
PR other/109306
* strstr.c: Revert the 2020-11-13 changes.
(strstr): Return s1 if len is 0.
2023-04-02 20:05:31 +02:00
|
|
|
|
|
|
|
if (!len)
|
|
|
|
return s1;
|
|
|
|
|
|
|
|
for (; (p = strchr (p, *s2)) != 0; p++)
|
1997-08-21 18:57:35 -04:00
|
|
|
{
|
libiberty: Make strstr.c in libiberty ANSI compliant
On Fri, Nov 13, 2020 at 11:53:43AM -0700, Jeff Law via Gcc-patches wrote:
>
> On 5/1/20 6:06 PM, Seija Kijin via Gcc-patches wrote:
> > The original code in libiberty says "FIXME" and then says it has not been
> > validated to be ANSI compliant. However, this patch changes the function to
> > match implementations that ARE compliant, and such code is in the public
> > domain.
> >
> > I ran the test results, and there are no test failures.
>
> Thanks. This seems to be the standard "simple" strstr implementation.
> There's significantly faster implementations available, but I doubt it's
> worth the effort as the version in this file only gets used if there is
> no system strstr.c.
Except that PR109306 says the new version is non-compliant and
is certainly slower than what we used to have. The only problem I see
on the old version (sure, it is not very fast version) is that for
strstr ("abcd", "") it returned "abcd"+4 rather than "abcd" because
strchr in that case changed p to point to the last character and then
strncmp returned 0.
The question reported in PR109306 is whether memcmp is required not to
access characters beyond the first difference or not.
For all of memcmp/strcmp/strncmp, C17 says:
"The sign of a nonzero value returned by the comparison functions memcmp, strcmp, and strncmp
is determined by the sign of the difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being compared."
but then in memcmp description says:
"The memcmp function compares the first n characters of the object pointed to by s1 to the first n
characters of the object pointed to by s2."
rather than something similar to strncmp wording:
"The strncmp function compares not more than n characters (characters that follow a null character
are not compared) from the array pointed to by s1 to the array pointed to by
s2."
So, while for strncmp it seems clearly well defined when there is zero
terminator before reaching the n, for memcmp it is unclear if say
int
memcmp (const void *s1, const void *s2, size_t n)
{
int ret = 0;
size_t i;
const unsigned char *p1 = (const unsigned char *) s1;
const unsigned char *p2 = (const unsigned char *) s2;
for (i = n; i; i--)
if (p1[i - 1] != p2[i - 1])
ret = p1[i - 1] < p2[i - 1] ? -1 : 1;
return ret;
}
wouldn't be valid implementation (one which always compares all characters
and just returns non-zero from the first one that differs).
So, shouldn't we just revert and handle the len == 0 case correctly?
I think almost nothing really uses it, but still, the old version
at least worked nicer with a fast strchr.
Could as well strncmp (p + 1, s2 + 1, len - 1) if that is preferred
because strchr already compared the first character.
2023-04-02 Jakub Jelinek <jakub@redhat.com>
PR other/109306
* strstr.c: Revert the 2020-11-13 changes.
(strstr): Return s1 if len is 0.
2023-04-02 20:05:31 +02:00
|
|
|
if (strncmp (p, s2, len) == 0)
|
|
|
|
return (char *)p;
|
1997-08-21 18:57:35 -04:00
|
|
|
}
|
|
|
|
return (0);
|
|
|
|
}
|