Re: regexprops-generic propagation

Bernhard Voelker wrote: > still it can take some months sometimes from a change in regex.h > until updating the gnulib submodule in findutils ... Oh, so a change in regex.h (in gnulib) propagates to a change in regexprops-generic.texi (in gnulib) via some tool that lives in the findutils repositor

Re: regexprops-generic propagation

Bernhard Voelker wrote: > * [PATCH 2/3] regexprops: sort regex_map alphabetically >https://cgit.git.sv.gnu.org/cgit/findutils.git/commit/?id=c9c2c511759 > > * [PATCH 3/3] doc: regenerate regexprops.texi >https://cgit.git.sv.gnu.org/cgit/findutils.git/commit/?id=facc27e1804 > > 2. Commit (

Re: new module 'hasmntopt'

mp; cd /tmp/testdir \ > && ./configure && make > > ... yields in gllib/mntent.h:584: > >#if && 1 Indeed. Thanks for the report. This patch fixes it: 2024-10-07 Bruno Haible mntent: Fix syntax error when module 'hasmntopt' is n

[bug #57277] FAIL: test-canonicalize-lgpl with GCC 10

Follow-up Comment #5, bug #57277 (project findutils): Fixed in gnulib today: https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=b7d7afe10ddf599452bd80b8a840c830cd474b09 ___ Reply to this item at:

[bug #57277] FAIL: test-canonicalize-lgpl with GCC 10

Follow-up Comment #4, bug #57277 (project findutils): > One can't decorate a function with nonnull attribute and then call the function with NULL. Doing that, an optimizing compiler can do aggressive optimizations. __attribute__ __nonnull__ actually means two things: 1) The compiler may emit warn

[bug #57277] FAIL: test-canonicalize-lgpl with GCC 10

773 100644 --- a/tests/test-canonicalize-lgpl.c +++ b/tests/test-canonicalize-lgpl.c @@ -16,6 +16,10 @@ /* Written by Bruno Haible , 2007. */ +/* Don't use __attribute__ __nonnull__ in this compilation unit. Otherwise the + undefined-behaviour of GCC or clang may let the test with

[bug #37201] Colourized output

Follow-up Comment #4, bug #37201 (project findutils): We now have a GNU library that makes it easy to implement user-customizable text styling. https://alpha.gnu.org/gnu/gettext/libtextstyle-0.8.tar.gz ___ Reply to this item at:

Re: posix_spawn_file_actions_addchdir

Eric Blake wrote: > http://austingroupbugs.net/view.php?id=1208 > > There, I argue that we also need posix_spawn_file_actions_addfchdir(), > in part because it lets us get the same power as openat() in determining > how relative file names are resolved in relation to an fd. The use-case is, AFA

Re: Introduce posix_spawn

Eric Blake wrote: > Although it gets prohibitively expensive in a multi-threaded process to > ensure proper locking between all threads that might want to use > posix_spawn Why locking? posix_spawn uses fork() - the vfork() optimization is not possible in the case when there are file actions -,

Re: posix_spawn_file_actions_addchdir

_01/html/E54847/golbg.html [3] https://docs.oracle.com/cd/E86824_01/html/E54766/posix-spawn-file-actions-addchdir-np-3c.html [4] https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-createprocessw [5] https://sourceware.org/ml/libc-alpha/2010-08/msg00109.

Re: findutils 4.6.0 v. Tru64 (strftime() v. "%F"?)

James Youngman wrote: > I'd need to update the > gnulib version so one which offers nstrftime (instead of the old name) This gnulib module is now called 'nstrftime'. Bruno

Re: rename strftime module

Bernhard Voelker asks: > Just out of curiosity: how did you find out? By source code inspection. I wanted to know how much trouble it would make to rename the module, and see whether I was the only one who feels confused by this module. Bruno

Re: rename strftime module

Bernhard Voelker wrote: > > 1) It suggests that it defines the function 'strftime', but in fact it > > defines 'nstrftime'. GNU findutils fell into this pit: their > > bootstrap.conf > > requests the gnulib 'strftime' module but the coded doesn't use > > nstrftime. > > What exactly d

Re: how to do findutils cross-compilation for ARM platform?

> > I met errors as > > arm-linux-gnueabi-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. > > -I../../intl -g -MT areadlink-with-size.o -MD -MP -MF $depbase.Tpo -c - o > > areadlink-with-size.o areadlink-with-size.c &&\ > > mv -f $depbase.Tpo $depbase.Po > > In file included f

Re: Documentation question

Reuben Thomas wrote: > gnulib people: you seem to be unhappy with code-generated > documentation. How would you like to proceed? It's OK to have documentation include pieces of the code if the extraction and update is done by us (the maintainers). What we would like to avoid is that people/distros

Re: [Patch] faster fnmatch

Hello Ondrej, Nice work already! > *abc* > en_US.UTF-8 > user: 2.71 > user: 0.23 > ... > *ab[a-z]* > en_US.UTF-8 > user: 2.85 > user: 3.32 > C > user: 0.86 > user: 1.25 Hmm, well, users are expecting a speedup through your module always. If it some (not too rare) cases the glibc fnmatch is

Re: faster fnmatch

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

Re: faster fnmatch

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 the pattern once and use it for matching often - the same approach that we

xargs dysfunctional after moving to a new machine

Hi, I built and installed findutils-4.2.32 on a Linux/x86 machine. Now I moved the binaries to a Linux/x86_64 machine (with libraries for execution of 32-bit mode binaries). The xargs program now does not work any more: $ echo x | xargs echo xargs: xargs.c:443: main: Assertion `bc_ctl.arg_max <=

Re: gnulib support for st_birthtime

James Youngman wrote: > this is a change which I cannot test since I > have no Woe32 system. I will push the change into findutils (instead > of using it indirectly in gnulib) and test it there for a bit. On the contrary, pushing the change into gnulib will make testing easier: If you provide a u

Re: [bug #8599] updatedb / locate is unusable over NFS

James Youngman wrote: > Follow-up Comment #3, bug #8599 (project findutils): > > I have added an item to the GNU Summer of Code project suggestions which is > a project to fix this problem. Would you be willing to mentor it? > > See http://www.gnu.org/software/soc-projects/ideas.html It's a nice

Re: [bug-gnulib] Re: findutils 4.2.27 on IRIX 5.3

Georg Schwarz wrote: > > findutils 4.2.27 does not compile on IRIX 5.3: > > [...] > > > cfe: Error: ./mbchar.h: 157: Cannot open file wchar.h for #include > > [...] > > > IRIX 5.3 does not have wchar.h. That was a bug in gnulib before 2005-09-26. Now, I believe everything is fine in gnulib: wchar.

Re: [bug-gnulib] Re: findutils-4.2.26 build error on HP-UX 10.20

Peter Fales wrote on 2005-11-22: > The error message occurs while building gnulib/lib (as part of > findutils-4.2.26): > > $ make > make all-am > make[1]: Entering directory > build/output/expmake/build/gnucoresrc/build/findutils/gnulib/lib' > /opt/exp/gnu/bin/gcc -DHAVE_CONFIG_H -I. -I. -I../..

Re: findutils doesn't compile on sunos 4.1.4

Derek Price asked: > In a recent discussion on bug-gnulib of the GNULIB stat & lstat modules, > GNULIB admins Jim Meyering, Bruno, and Paul Eggert agreed that it was no > longer useful to support SunOS 4.1.4 in GNULIB since even Sun stopped > supporting it over a year ago (handy dead OS reference h

Re: findutils doesn't compile on sunos 4.1.4

James Youngman wrote: > Certainly I believe that should > define NULL (though my copy of the standard isn't to hand). On SunOS 4, it doesn't. GNU gettext has this ChangeLog entry: 2001-10-31 Bruno Haible <[EMAIL PROTECTED]> * plural.y: Include , needed fo