bug in basename

Hello, I realized my fnmatch implementation contains this bug: For encodings like BIG5 if character contains / it could quit prematurely. I fixed it by ingoring FNM_PATHNAME till check phase. But as I looked how it is handled in basename.c it isnt handled at all. glibc basename too ignores this. -

Re: potential rbtree optimizations

On Sat, May 09, 2009 at 01:18:18AM +0200, Bruno Haible wrote: > Eric Blake wrote: > Anyone can add additional variants to the gnulib gl_list or gl_oset types. > I have no objection, but I won't spend time on doing endless variants of the > same thing. One could also implement Treap trees or some ot

Re: [Patch] faster fnmatch

-git a/lib/fnmatchcomp.c b/lib/fnmatchcomp.c new file mode 100644 index 000..b374fec --- /dev/null +++ b/lib/fnmatchcomp.c @@ -0,0 +1,632 @@ + /* Copyright (C) 2009 + Ondrej Bilka < nel...@seznam.cz > + + This program is free software: you can redistribute it and/or modif y + i

Re: [Patch] faster fnmatch

-0,0 +1,618 @@ + /* Copyright (C) 2009 + Ondrej Bilka < nel...@seznam.cz > + + This program is free software: you can redistribute it and/or modif y + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License,

Re: [Patch] faster fnmatch

ODULES.html.sh @@ -61,6 +61,7 @@ fenv float fmtmsg fnmatch +fnmatchcomp ftw glob grp @@ -418,6 +419,7 @@ fmodf fmodl fmtmsg fnmatch +fnmatchcomp fopen fork fpathconf diff --git a/lib/fnmatchcomp.c b/lib/fnmatchcomp.c new file mode 100644 index 000..2709e02 --- /dev/null +++ b/lib/fnm

[Patch] faster fnmatch

tch +fnmatchcomp fopen fork fpathconf diff --git a/lib/fnmatchcomp.c b/lib/fnmatchcomp.c new file mode 100644 index 000..e22074a --- /dev/null +++ b/lib/fnmatchcomp.c @@ -0,0 +1,458 @@ +/* Copyright (C) 2009 + Ondrej Bilka + +This program is free software; you can redistribute it

Re: faster fnmatch

On Fri, Apr 17, 2009 at 01:02:57PM +0200, Bruno Haible wrote: > Hello Ondrej, > > > > Hello. I am writing partial fnmatch to speed up locate et al. > > Cool! We know for some time already that this is a bottleneck [1]. > I find it also interesting that you go for a two-step approach, > preprocess

Re: faster fnmatch

On Fri, Apr 17, 2009 at 11:47:20AM +0200, James Youngman wrote: > On Thu, Apr 16, 2009 at 8:09 PM, Ondrej Bilka wrote: > > Hello. I am writing partial fnmatch to speed up locate et al. > > > > > Here is list what provided speedup and can be applied to original source &