Lorenzo Bettini wrote:
> However, I then noticed that there's dirent as a module (and opendir is
> declared in dirent.h) so I bet I should import dirent module anyway,
> shouldn't I?
When you look at the gnulib/lib/dirent.in.h file, you see that it declares
only functions; it provides no types,
Bruno Haible wrote:
Lorenzo Bettini wrote:
I saw that mkdir is a module in gnulib, while opendir (defined in
dirent.h) is not; thus opendir is assumed as standard?
Yes. You can see in the gnulib documentation [1] that no portability problems
are known for opendir().
This is because the only n
Ondrej Bilka wrote:
> I looked more into source and discovered fnmatch doesn't work as I imagined.
> By default it converts strings into widechars and match there.
> utf8 allows searching be done bitwise. Its in most cases faster.
fnmatch converts to wide characters because it often makes several
Lorenzo Bettini wrote:
> I saw that mkdir is a module in gnulib, while opendir (defined in
> dirent.h) is not; thus opendir is assumed as standard?
Yes. You can see in the gnulib documentation [1] that no portability problems
are known for opendir().
This is because the only native Windows port
Hi
I saw that mkdir is a module in gnulib, while opendir (defined in
dirent.h) is not; thus opendir is assumed as standard?
thanks in advance
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lore
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
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
> >
> > FOLD causes worst per
Pádraig Brady wrote:
> I wrote a quick test program on glibc-2.7 to show:
> malloc (0)==valid_ptr
> realloc (valid_ptr,0)==NULL
> realloc (NULL,0)==valid_ptr
> The interesting case there is the middle one which is not
> covered by the AC_FUNC_REALLOC check as far as I can see.
I confirm your
Chet Ramey wrote:
> That's a dangerous assumption. You can't always assume that fflush will
> succeed. And when it fails, newer versions of glibc leave data in the
> stdio buffer. Now, the assumption is that when fflush fails, it fails
> due to some problem with the underlying file descriptor, a
