current locale). Your comments about when it is safe to use c_strstr
> rather than mbsstr, even in the presence of multibyte sequence locales, is
> useful, but as far as I could see, those comments apply equally to strstr.
The point of c-strstr is
1) completeness of the c-str* functio
indicates that it's worth it.
* modules/c-strstr (Depends-on): Add stdbool, strnlen.
*** lib/c-strstr.c 11 Feb 2007 13:58:43 - 1.4
--- lib/c-strstr.c 11 Feb 2007 14:01:35 -
***
*** 21,27
/* Specification. */
#include "c-strstr.h&qu
The "check that the asymptotic worst-case complexity is not quadratic"
fails: it takes eternities. I'm therefore going to add a catch for
worst-case linear complexity. This is impossible with the current over-
optimized 'goto' spaghetti implementation, so I'm replacing it with a
maintainable implem
Hi,
I'm starting to speed up the substring search functions. First, a test case.
2007-02-11 Bruno Haible <[EMAIL PROTECTED]>
* modules/c-strstr-tests: New file.
* tests/test-c-strstr.c: New file.
== modules/c-s
Yoann Vandoorselaere wrote:
> > I don't think Chinese users will find it nice if you exclude them from
> > correct functioning of your program because of "performance" or "library
> > size".
>
> I don't think you are qualified to decide in place of the application
> developer whether the applicat
Yoann Vandoorselaere wrote:
> "However, if we have a platform missing strcasestr, then using
> c_strcasestr as the substitute implementation is probably okay, because
> that platform would probably be broken in other areas, such as locale
> support, ...
Solaris 9 and Solaris 10 (which also doesn't
On Tue, 2006-11-14 at 13:38 +0100, Bruno Haible wrote:
> Yoann Vandoorselaere wrote:
> > "However, if we have a platform missing strcasestr, then using
> > c_strcasestr as the substitute implementation is probably okay, because
> > that platform would probably be broken in other areas, such as loca
On Tue, 2006-11-14 at 14:58 +0100, Bruno Haible wrote:
> Yoann Vandoorselaere wrote:
> > > I don't think Chinese users will find it nice if you exclude them from
> > > correct functioning of your program because of "performance" or "library
> > > size".
> >
> > I don't think you are qualified to
Yoann Vandoorselaere wrote:
> Solaris 9 apparently lack the strcasestr() function.
If the program needs strcasestr(), then it needs the 'strcasestr' module.
It defines a replacement for strcasestr().
> Might we modify the
> c-strcasestr module so that it provide a replacement for platform
> lack
On Tue, 2006-11-14 at 11:40 +0100, Bruno Haible wrote:
> Yoann Vandoorselaere wrote:
> > Solaris 9 apparently lack the strcasestr() function.
>
> If the program needs strcasestr(), then it needs the 'strcasestr' module.
> It defines a replacement for strcasestr().
>
> > Might we modify the
> > c
On Fri, 2006-09-15 at 05:35 -0600, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Yoann Vandoorselaere on 9/15/2006 5:29 AM:
> > Hi,
> >
> > The c-ctype, c-strcase, c-strcasestr and c-strstr modules seem only to
> > i
This fixes a gcc warning with -Wmissing-prototypes.
2006-10-16 Bruno Haible <[EMAIL PROTECTED]>
* lib/c-strstr.c: Include c-strstr.h.
*** gnulib/lib/c-strstr.c 2006-09-14 15:42:08.0 +0200
--- gnulib-20061012/lib/c-strstr.c 2006-10-17 02:03:36.0 +0200
***
Yoann Vandoorselaere wrote:
> The c-ctype, c-strcase, c-strcasestr and c-strstr modules seem only to
> implement their replacement functions using a "c_" prefix.
>
> However, there is no autoconf test implemented by these modules that
> redefine the original function (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Yoann Vandoorselaere on 9/15/2006 5:40 AM:
>
> I recall platform missing strcasestr, although I can't remember which.
> Anyway, what's the purpose of these modules if they are not used
> anywhere ?
The c_* modules ARE used, particularly
On Fri, 2006-09-15 at 05:35 -0600, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Yoann Vandoorselaere on 9/15/2006 5:29 AM:
> > Hi,
> >
> > The c-ctype, c-strcase, c-strcasestr and c-strstr modules seem only to
> > i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Yoann Vandoorselaere on 9/15/2006 5:29 AM:
> Hi,
>
> The c-ctype, c-strcase, c-strcasestr and c-strstr modules seem only to
> implement their replacement functions using a "c_" prefix.
>
> However, there is
Hi,
The c-ctype, c-strcase, c-strcasestr and c-strstr modules seem only to
implement their replacement functions using a "c_" prefix.
However, there is no autoconf test implemented by these modules that
redefine the original function (in case it is missing) to point to their
GnuLib r
Paul Eggert wrote:
> > But it's important to know that c_strstr (s, "x") is not safe and
> > c_strstr (s, "123") is also not safe. The programmer needs to have the
> > precise criteria.
>
> I don't quite follow this. c_strstr (S, "x") is safe in all cases; it
> never has undefined behavior. I
Bruno Haible <[EMAIL PROTECTED]> writes:
> Therefore most of our "c-*" modules should better be called
> "ascii-*" or "unibyte-*".
But both ASCII and other unibyte locales might say that some bytes are
encoding errors. So none of these names are exactly right. I guess
c-* is as good a name as a
Bruno Haible <[EMAIL PROTECTED]> writes:
> The "nearly an ASCII extension" assumption is so ubiquitous, think of
> (c >= '0') tests and similar. You really find it's worth mentioning?
Digits are a very special case, because the C standard (C89
onward) guarantees that they are in order and contigu
Paul Eggert wrote:
> > /* The functions defined in this file assume the "C" locale and a character
> >set without diacritics (ASCII-US or EBCDIC-US or something like that).
> >Even if the "C" locale on a particular system is an extension of the
> > ASCII
> >character set (like on BeOS,
Thanks, that looks nice, but some quibbles about the comments:
> /* The functions defined in this file assume the "C" locale and a character
>set without diacritics (ASCII-US or EBCDIC-US or something like that).
>Even if the "C" locale on a particular system is an extension of the ASCII
>
The module strstr is internationalized, fine. But there are some cases
where it's overkill and the classical and faster byte-per-byte string
traversal can be used instead. I propose to add a new module c-strstr
in the same philosophy as c-ctype, c-strcase, c-strca
23 matches
Mail list logo
