Bruno Haible wrote:
2008-11-18 Alexandre Duret-Lutz [EMAIL PROTECTED]
Bruno Haible [EMAIL PROTECTED]
The above line needs a hard tab to pass `make syntax-check`
in coreutils at least.
cheers,
Pádraig.
Bruno Haible wrote:
Pádraig Brady wrote:
2008-11-18 Alexandre Duret-Lutz [EMAIL PROTECTED]
Bruno Haible [EMAIL PROTECTED]
The above line needs a hard tab to pass `make syntax-check`
in coreutils at least.
I'm sorry, but the gnulib ChangeLog is not among the files
Bruno Haible wrote:
The list of warnings that I would disable unconditionally would be:
warnings=$warnings -Wno-sign-compare # These warnings usually don't
point to mistakes.
Usually -Wsign-compare warnings don't point to mistakes,
but they can point to non obvious mistakes
(which may
Not sure if it's a bug but it is confusing.
I have a little wrapper script that I've been
using for years to bypass this issue:
http://www.pixelbeat.org/scripts/day
Pádraig.
Paolo Bonzini wrote:
A while ago I made a lot of timings regarding the speed of various shell
constructs; you can find them on the Autoconf list. Here are the
relevant ones:
$ time sh -c 'for i in `seq 1 1000`; do :; done'
user0m0.034s
sys 0m0.024s
$ time sh -c
Albert Chin wrote:
When gl_VSNPRINTF_ZEROSIZE_C99 is run under the Sun C++ compiler on a
recent Solaris release, it fails because of:
static char buf[8] = DEADBEEF;
The compiler complains with:
Error: Cannot use const char[9] to initialize char[8].
So, just replace `8' with `9'?
Bruno Haible wrote:
Jim Meyering wrote:
I wrote these changes some time ago, and
am going to push them shortly.
+#undef UNUSED_PARAM
+#ifdef __linux__
+# define UNUSED_PARAM _UNUSED_PARAMETER_
+#else
+# define UNUSED_PARAM
+#endif
+
...
+#undef UNUSED_PARAM
+#ifdef GETFSTYP
+#
Jim Meyering wrote:
Bruno Haible wrote:
...
With this, you can easily create a program that reads UTF-8 from stdin and
outputs it as canonicalized UTF-8 on stdout:
- create a stream that takes a Unicode character and outputs it to
stdout. (Gnulib module 'unistr/u8-uctomb'.)
- Wrap a
Bruno Haible wrote:
I'm adding functions for comparing Unicode strings, while ignoring their
normalization form.
*** lib/uninorm.h.orig2009-03-06 19:20:21.0 +0100
--- lib/uninorm.h 2009-03-06 19:01:38.0 +0100
+ /* Compare S1 and S2, ignoring normalization.
Bruno Haible wrote:
Pádraig Brady wrote:
+ /* Compare S1 and S2, ignoring normalization.
ignoring normalization is confusing.
Is it more understandable if I say Compare S1 and S2, ignoring differences
in normalization?
better, thanks.
I presume you mean Compare normalized versions
Bruno Haible wrote:
Hi Jim,
Thanks for looking at this Bruno.
In coreutils/src/join.c, there is a FIXME mentioning that the -i option for
case insensitive comparison of the input lines does not work in multibyte
locales.
Utils that have this issue are:
join -i, uniq -i, sort -f, ptx -f
Pádraig Brady wrote:
Bruno Haible wrote:
Hi Jim,
Thanks for looking at this Bruno.
In coreutils/src/join.c, there is a FIXME mentioning that the -i option for
case insensitive comparison of the input lines does not work in multibyte
locales.
Utils that have this issue are:
join -i
Markus Duft wrote:
Hi!
I have a more or less trivial patch for the nanosleep replacement for
interix. The problem I ran into is, that select() has a bug, making it fail
with bad address if the number of fd's to select on is zero. Setting the
set-size to 1 solves the problem, and should not
Jim Meyering wrote:
ipif wrote:
I'm using coreutils-7.2 on an embedded sparc V8 with linux-2.6.21 and
uclibc-0.9.30.
The problem is, that in utime.c(73) it is tried to read a char from the file
and to write it back. As the fifo is empty touch gets stuck waiting for
input.
Because I'm
Andreas Schwab wrote:
Pádraig Brady p...@draigbrady.com writes:
So would this simplification be appropriate, which just handles systems
where utime(file, ut); is OK while utime(file, NULL); is not?
Note that utime(,0) requires less privileges than utime(,ut). For the
latter you need
I was looking at what was provided by the realloc module in gnulib
and was a bit confused. There was no texi info on it and the description
in modules/realloc just says realloc() function that is glibc compatible.
For me, that wasn't enough info to infer how I should use realloc().
The module
Bruno Haible wrote:
Pádraig Brady wrote:
... then we need to use realloc like this I think:
errno=0
np = realloc (p, n);
if (np==NULL errno==ENOMEM) {
free (p);
error ();
}
I.E. xrealloc etc. should be changed to check ENOMEM as above?
This way of checking realloc's
Jim Meyering wrote:
Eric Blake wrote:
Jim Meyering jim at meyering.net writes:
@@ -20,4 +20,4 @@
#include wchar.h
/* Internal state used by the functions mbsrtowcs() and mbsnrtowcs(). */
-mbstate_t _gl_mbsrtowcs_state = 0;
+mbstate_t _gl_mbsrtowcs_state = { 0, };
Is this correct for
Jim Meyering wrote:
I expect to push this shortly.
Thank you!
From 372c3b4a79def664b8fa73316c35caf39bf93e2c Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano gscriv...@gnu.org
Date: Fri, 1 May 2009 09:23:20 +0200
Subject: [PATCH] getdate: correctly interpret next monday when run on a
Monday
I can see this causing compat issues?
http://blog.aurel32.net/?p=47
Is there anything we could/should do to avert it?
cheers,
Pádraig.
Pádraig Brady wrote:
I noticed another thread with more info about fallocate:
https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00110.html
That got me thinking about whether we should use fallocate()
if available in cp etc. so ext4 etc. can allocate optimally?
Here
Bruno Haible wrote:
Hello Pádraig,
The documentation files you sent document the status before any 'fallocate'
module is added to gnulib. So I committed them for you:
2009-05-21 Pádraig Brady p...@draigbrady.com
* doc/glibc-functions/fallocate.texi: New file.
* doc
Paul Eggert wrote:
Pádraig Brady p...@draigbrady.com writes:
Well libc, kernel or filesystem could return ENOSYS
so code using fallocate() has to handle it anyway.
If memory serves, ordinarily gnulib tries to catch such situations,
and to substitute a working function when the kernel just
Eric Blake wrote:
According to Pádraig Brady on 5/27/2009 10:20 AM:
Take 2 attached.
Still outstanding from the gnulib portion is support for solaris.
I may get time to set this up, but I've very little time lately,
so I would like not to require this for merging.
That seems like
Bruno Haible wrote:
Pádraig Brady wrote:
Take 2 attached.
Take 2 review:
+#ifdef REPLACE_FALLOCATE
The generated fcntl.h should be maximally standalone. Can you better use
#if @REPLACE_FALLOCATE@ and use an AC_SUBSTed variable REPLACE_FALLOCATE
instead of one defined in config.h?
I
Pádraig Brady wrote:
Bruno Haible wrote:
The return value convention described in
http://www.kernel.org/doc/man-pages/online/pages/man2/fallocate.2.html
is a different one. Either this code or that man page is wrong.
I don't follow. Both return int. ENOSYS to me means it can't be done
Paolo Bonzini wrote:
It would be nice to have something in coreutils doing normalization...
Bruno discussed adding a `unorm` util previously which we're considering:
http://lists.gnu.org/archive/html/bug-coreutils/2009-02/threads.html#00224
The alternative existing `uconv` mentioned in that
I noticed the use of ignore-value() recently and
was a little confused by it. How about the attached tweaks
to make it explicit it doesn't handle all return types
and also remove the use of __attribute__ ((__unused__))
which I don't think is required.
cheers,
Pádraig.
From
Jim Meyering wrote:
Hmm... I guess you could be thinking about
warnings from non-gcc compilers. Yes, that's another way in which
(void)i is better.
Right.
BTW, I'm annoyed that one can't always do: (void) function();
but I presume gcc must have a _very_ good reason for that.
How about this
Bruno Haible wrote:
On an NFSv3 file system on Solaris 10 a gettext fails during qset_acl:
msgmerge: preserving permissions for `mm-u-2.po~': Operation not supported on
transport endpoint
FAIL: msgmerge-update-2
This fixes it.
2009-08-30 Bruno Haible br...@clisp.org
Fix
Bruno Haible wrote:
Pádraig Brady wrote:
I was wondering about this general issue a couple of days ago when pondering:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=2bc0f3c
At the application level we often want to check for this
not supported condition while not caring
Jim Meyering wrote:
Eric Blake wrote:
According to Pádraig Brady on 10/5/2009 3:53 PM:
This is a new test, but FC5 is s old,
that I'm not sure it's worth worrying about.
March 2006?
The failure is probably a function of the kernel.
Which is it?
In summary this is what fails:
$ touch
Jim Meyering wrote:
Pádraig Brady wrote:
Jim Meyering wrote:
Eric Blake wrote:
According to Pádraig Brady on 10/5/2009 3:53 PM:
This is a new test, but FC5 is s old,
that I'm not sure it's worth worrying about.
March 2006?
The failure is probably a function of the kernel.
Which
Paolo Bonzini wrote:
On 10/06/2009 11:05 AM, Pádraig Brady wrote:
Also a minor nit in s/Linux/Gnu\/Linux/
Definitely not when it's talking explicitly of a kernel version?
Right, it could be GNU/Linux or Linux kernels? (.*)?
cheers,
Pádraig.
I was going to mention some optional packages for coreutils in README-prereq
libselinux-devel
libcap-devel
libattr-devel
gmp-devel
libacl-devel
However these names are linux specific and probably even fedora specific,
so what would be better I think is for configure to give
Jim Meyering wrote:
What do you think about suggesting with each how to install
the missing package, e.g.,
You can install the required libgmp.* files
via yum install gmp-devel on a fedora-based system,
or apt-get install gmp-devel on a debian-based system.
The easier we
Bruno Haible wrote:
Pádraig Brady wrote:
configure: WARNING: libacl development library was not found or not
usable.
configure: WARNING: GNU coreutils will be built without ACL support.
configure: WARNING: libselinux was found but selinux/selinux.h is
missing.
configure
Jim Meyering wrote:
Pádraig Brady wrote:
p.s. I'll look at bypassing stdio on input to see
if I can get at least the 2% back
IMHO, even if it did, it would not be worth it.
Right, a quick test here shows only a 0.8% gain from
bypassing stdio. However I also noticed that the
digest
Paolo Bonzini wrote:
On 10/22/2009 01:09 PM, Pádraig Brady wrote:
Jim Meyering wrote:
Pádraig Brady wrote:
p.s. I'll look at bypassing stdio on input to see
if I can get at least the 2% back
IMHO, even if it did, it would not be worth it.
Right, a quick test here shows only a 0.8% gain
Jim Meyering wrote:
Pádraig Brady wrote:
...
copy_file_preserving (const char *src_filename, const char *dest_filename)
@@ -58,8 +60,7 @@ copy_file_preserving (const char *src_filename, const char
*dest_filename)
struct stat statbuf;
int mode;
int dest_fd;
- char buf[4096
Jim Meyering wrote:
Pádraig Brady wrote:
diff --git a/lib/md2.c b/lib/md2.c
index cb4c63b..f8878c0 100644
--- a/lib/md2.c
+++ b/lib/md2.c
@@ -33,7 +33,7 @@
# include unlocked-io.h
#endif
-#define BLOCKSIZE 4096
+#define BLOCKSIZE 32768
#if BLOCKSIZE % 64 != 0
# error invalid
Jim Meyering wrote:
Pádraig Brady wrote:
...
diff --git a/lib/copy-file.c b/lib/copy-file.c
...
+enum { IO_SIZE = 32*1024 };
Almost there.
I like the enum.
Did you consider making BLOCKSIZE, below, an enum, too?
as long as you're changing it...
I did consider, but that would involve
Bruno Haible wrote:
Pádraig Brady wrote:
Hmm it's a bit surprising that min()/max() are not available
as $((shell arithmetic)) or in `expr`. Consequently I agree that
adding the option you suggest is useful.
But min() and max() are available through the 'test'
program or shell built
Paolo Bonzini wrote:
Some programs, like 'msgmerge' from GNU gettext, already pay
attention to the OMP_NUM_THREADS variable - a convention shared
by all programs that rely on OpenMP. Can you make the 'sort'
program use the same convention?
I am not working on the multi-threaded sort, but
Pádraig Brady wrote:
Paolo Bonzini wrote:
Of course this should only apply if its effect is not externally
observable; if I have a very small file B and a very large file A, and I
can get
$ md5sum --threads A B
abcdabcdabcdabcdabcdabcdabcdabcd B
Paolo Bonzini wrote:
Maybe we want a --parallel option (too bad -p is taken) for xargs that
forces the creation of the number of processes passed with -P or taken
from nproc (for example by starting md5sum $1 $5 $9 ..., md5sum $2 $6
$10 ..., etc.)?
That would be an interesting alternative to
On 25/10/10 01:26, Pádraig Brady wrote:
I noticed large realloc()s still being done by fread_file() for the
common case of a regular file. As well as being inefficient,
it could needlessly fail for large files.
$ truncate -s1M t.f
$ ltrace ./a.out t.f
malloc(1048577
On 13/12/10 17:50, Paul Eggert wrote:
On 12/13/10 02:09, Pádraig Brady wrote:
* Keep allocation to multiples of BUFSIZ which may be more efficient
I don't see how the patch accomplishes this.
If alloc starts off being BUFSIZ, and the assignment
alloc = alloc + alloc / 2 does not keep
On 14/12/10 07:04, Ralf Wildenhues wrote:
Trying out gold (no LTO) on GCC's cc1, a log shows that the single
biggest part (20%) of user time for such a medium sized program may be
spent in SHA1 computation for the build id. I think the SHA1 code in
libiberty would benefit from an SSE
On 21/11/10 01:31, Bruno Haible wrote:
2010-11-20 Bruno Haible br...@clisp.org
Port to uClibc.
...
Oops, that patch and its ChangeLog entry were incomplete.
Here is the corrected ChangeLog:
2010-11-20 Bruno Haible br...@clisp.org
Port to uClibc.
*
On 23/06/10 01:39, Pádraig Brady wrote:
On 22/06/10 15:42, Eric Blake wrote:
On 06/22/2010 08:41 AM, Eric Blake wrote:
On 06/22/2010 08:34 AM, Pádraig Brady wrote:
Cool, that's what I expected from the names.
So do we just need to move a docs around a little like:
Yes, that looks like
On 05/01/11 11:22, Jim Meyering wrote:
Pádraig Brady wrote:
...
Cool, thanks for doing that.
It probably needs this too:
#ifndef __attribute__
/* The __attribute__((__deprecated__) feature
is available in gcc versions 3.1 and later. */
# if __GNUC__ 3 || (__GNUC__ == 3
That looks much better, thanks!
How about the follow on patch to fixup comments?
I'll update coreutils to your commit now...
cheers,
Padraig.
commit 693a832795d6c63584db16baf163bccdc725dab6
Author: Pádraig Brady p...@draigbrady.com
Date: Fri Jan 7 01:25:06 2011 +
ignore-value:
On 31/07/10 20:48, Bruno Haible wrote:
Hi Pádraig,
the u8_strstr function.
I wonder could we speed that up for UTF-8
by just deferring to strstr() ?
This is a good idea, because the naïve implementation of u8_strstr is
quadratic (O(n²)), whereas for strstr we now have an O(n) algorithm.
On 20/01/11 20:25, Eric Blake wrote:
On 01/20/2011 01:16 PM, Pádraig Brady wrote:
On 31/07/10 20:48, Bruno Haible wrote:
Hi Pádraig,
the u8_strstr function.
I wonder could we speed that up for UTF-8
by just deferring to strstr() ?
This is a good idea, because the naïve implementation
commit b10e578396a2fd33e898b23d31fe49998c88c643
Author: Pádraig Brady p...@draigbrady.com
Date: Fri Jan 21 08:17:07 2011 +
ignore-value: remove dependency on stdint
Since commit 939dedd9, 06-01-2011,
ignore-value: support aggregate types
we no longer need stdint (intptr_t
commit a00e384e1d7bbf0d4961b6f355307fd78b7536dd
Author: Pádraig Brady p...@draigbrady.com
Date: Fri Jan 21 08:47:51 2011 +
test-malloca: unset MALLOC_PERTURB_ to speed up test
* tests/test-malloca.c (main): Unset the environment variable
to greatly speed up the test
I noticed od was very slow and traced it to it using xprintf:
$ timeout 2 od-xprintf -Ax -tx1z -v /dev/zero | pv /dev/null
3.66MB 0:00:02 [1.86MB/s]
$ timeout 2 od-printf -Ax -tx1z -v /dev/zero | pv /dev/null
19.6MB 0:00:02 [9.96MB/s]
The reason is because xprintf pulls in the whole gnulib
On 03/02/11 11:18, Bruno Haible wrote:
Hello Pádraig,
The reason is because xprintf pulls in the whole gnulib vasnprintf
implementation, and then it does a huge number of reallocs.
Did a profiling reveal where in vasnprintf the speed problems are?
All I did was narrow it down to reallocs.
Sorry, just getting back to this now...
To recap, od using xprintf gives this throughput:
$ timeout 2 od -Ax -tx1z -v /dev/zero | pv /dev/null # 1.58MB/s
There was lots of heap interaction going on,
and by using the attached patch (only illustrative, may leak,
is not thread safe, ...) to cache
On 04/02/11 18:23, Bruno Haible wrote:
Hi Pádraig,
There was lots of heap interaction going on,
and by using the attached patch (only illustrative, may leak,
is not thread safe, ...) to cache the PRINTF_PARSE result
it increases the throughput to 5.8MB/s
Adding a global cache like this
On 02/03/11 17:10, Paul Eggert wrote:
On 03/02/2011 07:09 AM, Jim Meyering wrote:
- struct argv_iterator *ai = malloc (sizeof *ai);
+ struct argv_iterator *ai;
+ struct stat st;
+
+ if (fstat (fileno (fp),st) == 0 S_ISDIR (st.st_mode))
+{
+ errno = EISDIR;
+ return
A recent change to dd in coreutils triggered this issue,
which is avoided with the attached.
cheers,
Pádraig.
From 3d1a414c90c49f3b4d9e427e4024f511adff154c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Fri, 11 Mar 2011 01:12:56 +
Subject: [PATCH]
On 11/03/11 09:32, Jim Meyering wrote:
Pádraig Brady wrote:
A recent change to dd in coreutils triggered this issue,
which is avoided with the attached.
Thanks!
I've pushed that.
Cool, thanks.
I have gnulib commit access BTW
I had a local tweak to remove an extraneous ( in the Changelog
On 11/03/11 13:50, Eric Blake wrote:
On 03/11/2011 02:32 AM, Jim Meyering wrote:
Pádraig Brady wrote:
A recent change to dd in coreutils triggered this issue,
which is avoided with the attached.
sc_unmarked_diagnostics:
@grep -nE
On 24/03/11 17:17, Eric Blake wrote:
C99 requires realloc(p,0) to either successfully allocate a 0-sized
array (just like malloc(0)) or to return NULL and leave p unchanged.
glibc treats realloc(p,0) like free(p) (as permitted by C89), and using
C99 compliant code would thus result in a
On 31/03/11 15:20, Eric Blake wrote:
Sounds to me like the gnulib fallback should be made smarter. Which
systems lack linkat() but have the capability to set timestamps? BSD?
But the original report was about opensuse, which is Linux based, and my
recollection is that Linux handles hardlinks
On 05/04/11 13:36, Philipp Thomas wrote:
GNU find will not recognize file systems of type autofs on newer Linux
kernels as autofs entries are only listed in /proc/mounts and mountlist.c
includes glibc mntent.h which takes the _PATH_MOUNTED from paths.h and that
is /etc/mtab.
After a longer
On 06/04/11 12:03, Karel Zak wrote:
On Tue, Apr 05, 2011 at 03:18:02PM +0100, Pádraig Brady wrote:
On 05/04/11 13:36, Philipp Thomas wrote:
GNU find will not recognize file systems of type autofs on newer Linux
kernels as autofs entries are only listed in /proc/mounts and mountlist.c
includes
On 05/04/11 03:26, Paul Eggert wrote:
This gnulib patch modifies verify to use C1X's _Static_assert if
running GCC 4.6.0 or later, which generates easier-to-read
diagnostics. I haven't pushed this yet because I thought it wouldn't
hurt to get more pairs of eyes to look at it.
So C++0x
On 09/04/11 01:14, Bruno Haible wrote:
Hi Paul,
+# if 0 defined __cplusplus
+# define HAVE_STATIC_ASSERT 1
+# endif
That 0 looks wrong: did you put it in for debugging,
and intend to remove it before installing?
The intent of this 0 condition was to be a placeholder until GCC 4.7
On 27/04/11 16:47, J.T. Conklin wrote:
First some background.
The continuous integration build framework I maintain at work uses
timestamp files for last_build, last_success, etc. The contents
of each file is the timestamp in ISO 8601 format (the inode mtime is
set to the same value, but
On 29/04/11 22:00, Jim Meyering wrote:
Eric Blake wrote:
On a glibc system, Coverity gives this warning:
Error: UNINIT:
m4-1.4.16/lib/fatal-signal.c:183: var_decl: Declaring variable action
without initializer.
m4-1.4.16/lib/fatal-signal.c:198: uninit_use_in_call: Using uninitialized
On 29/04/11 22:15, Pádraig Brady wrote:
On 29/04/11 22:00, Jim Meyering wrote:
Eric Blake wrote:
On a glibc system, Coverity gives this warning:
Error: UNINIT:
m4-1.4.16/lib/fatal-signal.c:183: var_decl: Declaring variable action
without initializer.
m4-1.4.16/lib/fatal-signal.c:198
On 30/04/11 00:26, Eric Blake wrote:
Looks nice from my reading of it. Although for the cache variable
names, should we go with gl_cv_cc_nomfi_supported rather than
gl_cv_nomfi_supported (that is, add cc_ to each of the cache variable
names), to make it clear that the cache variables are all
On 30/04/11 12:13, Bruno Haible wrote:
Pádraig Brady wrote:
I've amended that, and the indenting issue Bruno noticed, and pushed.
That file also has other indentation issues: the basic indentation
sometimes is 1, sometimes 2, even in the same statement. I'm fixing it:
I notice the serial
I've noticed a few times when re-running bootstrap
within my coreutils directory, that the build will fail because
it seems that the timestamps of the symlinks in m4/ are used,
rather than those of the target m4 files.
For example recently, @HAVE_SIGHANDLER_T@ was left unsubstituted in
On 12/05/11 16:04, Jim Meyering wrote:
Eric Blake wrote:
On 05/12/2011 08:55 AM, Eric Blake wrote:
Then again, './gnulib-tool --with-tests --test fclose' worked for me.
Is this a case of you building incrementally but the replacement
stdio.h for iwhd hasn't been replaced to reflect the change
On 14/05/11 09:07, Paul Eggert wrote:
If something treats symlink mtime as significant,
then I suspect that it's at fault.
Yes, there's something busted there. GNU 'make' does the right thing:
it follows symlinks when checking time stamps. Is some other 'make'
is being used, or perhaps
On 16/05/11 20:47, Ralf Wildenhues wrote:
Hi Pádraig,
* Pádraig Brady wrote on Mon, May 16, 2011 at 04:44:42PM CEST:
On 14/05/11 09:07, Paul Eggert wrote:
If something treats symlink mtime as significant,
then I suspect that it's at fault.
Yes, there's something busted there. GNU 'make
I just noticed this excellent paper on AIR integers
http://www.cert.org/archive/pdf/09tn023.pdf
which also summarizes other run-time integer
overflow handling methods, including precondition testing
as implemented by Paul's handy new macros.
cheers,
Pádraig.
On 09/05/11 11:44, Jim Meyering wrote:
I've been using a precursor of this rule in coreutils for many years,
so finally have made it general enough so that the same
The above change is giving a false positive on my 32 linux laptop,
where it flags __i686.get_pc_thunk.bx from
On 17/05/11 15:08, Jim Meyering wrote:
Pádraig Brady wrote:
On 09/05/11 11:44, Jim Meyering wrote:
I've been using a precursor of this rule in coreutils for many years,
so finally have made it general enough so that the same
The above change is giving a false positive on my 32 linux laptop
On 17/05/11 15:23, Pádraig Brady wrote:
Given '^__.*' names are reserved by the compiler,
perhaps the happy medium is to to allow single underscores,
but exclude double underscores, with something like:
I'm going with the following, so as to not put the
onus on users configuring an exclude
On 31/05/11 01:28, James Youngman wrote:
[ CC += bug-findutils, += Paolo, -= bug-coreutils ]
2009/11/3 Pádraig Brady p...@draigbrady.com:
Pádraig Brady wrote:
Paolo Bonzini wrote:
Maybe we want a --parallel option (too bad -p is taken) for xargs that
forces the creation of the number
On 31/05/11 01:14, James Youngman wrote:
On Tue, Apr 5, 2011 at 1:36 PM, Philipp Thomas p...@suse.de wrote:
GNU find will not recognize file systems of type autofs on newer Linux
kernels as autofs entries are only listed in /proc/mounts and mountlist.c
includes glibc mntent.h which takes the
On 06/07/11 08:52, Paul Eggert wrote:
No serial number here?
I still don't get why hand-maintained serial numbers are useful
in m4/*.m4 files (and nowhere else?!). Maybe they were useful
long ago, but their cost outweighs their benefit now, as far as
I can see.
I got this answer when
On 10/07/11 10:56, James Youngman wrote:
I just went to use some function attributes in findutils and noticed
that information about which versions of GCC support various
attributes is spread throughout gnulib. While a number of headers
define convenience macros (usually starting
On 12/07/11 00:21, Eric Blake wrote:
Libvirt wants to use ffs() to avoid dragging in -lm for log2().
This is a useful module.
+#include strings.h
+
+int
+ffs (int i)
+{
+#if __GNUC__ 3 || (__GNUC__ == 3 __GNUC_MINOR__ = 4)
+ return __builtin_ffs (i);
+#else
+ /*
On 14/07/11 23:33, Paul Eggert wrote:
[CC'ing bug-gnulib re http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9076.]
On 07/13/11 23:54, Joachim Schmitz wrote:
coreutils-8.12 uses SA_RESETHAND and SA_RESTART unconditionally and on HP
NonStop these don't exist.
Thanks for reporting this. I
On 15/07/11 08:50, Paul Eggert wrote:
On 07/14/11 17:25, Pádraig Brady wrote:
I'm not sure about defining these to 0 in gnulib.
That will silently ignore the intent of a program on certain platforms.
Wouldn't it be better to fail to compile so that each program then does:
#ifndef
On 07/07/11 17:57, Eric Blake wrote:
Use of W; in an option string may be rare, but we might as well
avoid crashing on it.
* m4/getopt.m4 (gl_GETOPT_CHECK_HEADRS): Detect the problem.
I noticed core files which are due to this I think.
Should it be protected with m4/nocrash.m4 ?
cheers,
On 19/07/11 16:34, Eric Blake wrote:
On 07/19/2011 03:55 AM, Pádraig Brady wrote:
On 07/07/11 17:57, Eric Blake wrote:
Use of W; in an option string may be rare, but we might as well
avoid crashing on it.
* m4/getopt.m4 (gl_GETOPT_CHECK_HEADRS): Detect the problem.
I noticed core files
On 19/07/11 19:45, Paul Eggert wrote:
On 07/19/11 04:00, Pádraig Brady wrote:
+ if (timer_create (CLOCK_REALTIME, NULL, timerid) == -1)
+error (EXIT_FAILURE, errno, _(error in timer_create));
+ if (timer_settime (timerid, 0, its, NULL) == -1)
+error (EXIT_FAILURE, errno, _(error
On 20/07/11 02:30, Bruno Haible wrote:
Pádraig Brady wrote:
[timer-time.diff attachment]
+Check for timer_settime. Within HAVE_TIMER_SETTIME one can
+assume timer_create is available too, as that is a
+prerequisite to use timer_settime.
And timer_gettime as well. I've verified
On 16/07/11 01:51, Paul Eggert wrote:
On 07/15/11 03:28, Pádraig Brady wrote:
What I was getting was that it's probably better to leave
the following to the app too:
#ifndef SA_RESETHAND
# define SA_RESETHAND 0
/* Now the app writer knows they need to handle this case */
#endif
Yes
On 22/07/11 18:22, Paul Eggert wrote:
Here's another module I'm adding to coreutils.
I plan to change coreutils to use it.
Another possibility, I suppose, would be to fold it into
AC_SYS_LARGEFILE.
Herb, can you please try out the effect of this module by
appending #define
On 24/07/11 11:39, Bruno Haible wrote:
--- modules/close.origSun Jul 24 12:37:10 2011
+++ modules/close Sun Jul 24 12:29:07 2011
@@ -8,7 +8,6 @@
Depends-on:
unistd
fd-hook [test $REPLACE_CLOSE = 1]
-fclose
Do we also need to remove the gl_REPLACE_FCLOSE call from
On 08/18/2011 02:53 PM, Jim Meyering wrote:
A few weeks ago, I noticed that removing a directory with very many
entries made rm -rf use an inordinate amount of memory. I've fixed the
underlying fts module to batch its readdir calls in the common case,
thus to imposing a reasonable ceiling on
On 08/18/2011 09:14 PM, Jim Meyering wrote:
Pádraig Brady wrote:
With the default threshold of 100,000, the maximum is under 30MB
and slightly faster than the first run:
...
0
+---Gi
0
1 - 100 of 814 matches
Mail list logo
