On 07/23/10 09:13, Eric Blake wrote:
http://lists.gnu.org/archive/html/bug-coreutils/2010-07/msg00100.html
I think porting cmp to use this would be a nice optimization
Thanks, good suggestion! Also, diff should do it.
On 10/18/10 10:19, Ulf Zibis wrote:
IMO this is a bug, or should be documented more explicit.
I'd say fix the doc. Do you have a suggestion for
improving the wording?
ff50010c65f0eb4ad4fade6b65ce8f349b13e31f Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Sat, 23 Oct 2010 17:20:01 -0700
Subject: [PATCH] du: don't print junk when diagnosing out-of-range time stamps
* src/du.c (show_date): Fix call to fputs with a buffer that
contains some uninitialized
On 11/28/10 23:14, DJ Lucas wrote:
http://lists.gnu.org/archive/html/coreutils/2010-11/msg00124.html
Ah, sorry, I didn't understand that message and thought Pádraig
had handled it. On an 8-core RHEL 5.5 x86-64 host I reproduced
the problem with the stated test case:
(for i in $(seq 12); do
On 11/30/2010 10:16 PM, Paul Eggert wrote:
Invoke MAX_MERGE(total, level) with level == 15.
2 level yields 65536, and 65536 * 65536 overflows to zero.
I managed to reproduce this bug on a (faked) host with
32768 processors, using a command like this:
seq 10 | sort --parallel=32768
On 12/02/10 02:22, Chen Guo wrote:
On Mon, Nov 29, 2010 at 11:16 AM, Paul Eggert egg...@cs.ucla.edu wrote:
(for i in $(seq 12); do read line; echo $i; sleep .1; done
cat /dev/null) fifo
(ulimit -t 1; ./sort in fifo \
|| echo killed via $(env kill -l $(expr $? - 128)))
I ran this 10
On 12/03/10 12:18, Chen Guo wrote:
I'll try out Professor Eggert's suggestion, of switching to mutexes
only at the top level merge.
I'm having second thoughts about that. Yes, that'll prevent the
top-level merge (which is generating the actual output) from chewing
up CPU time. But it already
On 11/29/2010 02:46 PM, Paul Eggert wrote:
My current guess, by the way,
is that it's not a bug that can be triggered: it's merely
useless code that is harmless and can safely be removed.
I removed it as part of the following series of cleanup
patches. These are intended merely to refactor
On 12/05/2010 09:16 PM, Chen Guo wrote:
Before saying anything else, I should note that for mutexes, on 4
threads 20% of the time there's a segfault on a seemingly innocuous
line in queue_insert ():
node-queued = true
It does sound like mutexes are the way to go, and that this bug
needs to
My recent patch had a typo in a comment, which I fixed as follows:
From 7e9599422e85be01dfceecf1f38ff2c2952a3f61 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Mon, 13 Dec 2010 10:02:06 -0800
Subject: [PATCH] tests: typo fix
* tests/misc/sort-stale-thread-mem: Fix typo
2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Tue, 14 Dec 2010 10:07:36 -0800
Subject: [PATCH] tests: default to /tmp as the temporary directory
* tests/check.mk (TESTS_ENVIRONMENT): Default TMPDIR to /tmp,
rather than to the working directory; this is more common in
practice, which makes
This bug has been there for ages, I think. It's unrelated to
the other bugs recently discussed, but I found it by code inspection
while looking into the other ones. I don't see any practical
way to test for it. I pushed this:
* src/sort.c (avoid_trashing_input): Fix a typo that could cause a
pushed the following
patch to fix the problem. (And now I really must stop looking at
'sort' for a bit!)
From f7afbe67f1587c79b43779aa95502fcee564c20e Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Thu, 16 Dec 2010 22:31:56 -0800
Subject: [PATCH] sort: do not generate thousands
I found this one by tracking down a bug with the latest snapshot
on Solaris. Still haven't got to the real bug yet, but this bug
was getting in the way.
From 7669bee6d7e9d0e806e42cb1033bd2b6642b7e9a Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Fri, 17 Dec 2010 22:39:47
/ChangeLog
index 8b02175..1ee355c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2010-12-18 Paul Eggert egg...@cs.ucla.edu
+
+ tests: set fail=0 at start
+ * tests/init.sh (setup_): Move fail=0 initialization here ...
+ (mktempd_): ... from here, so that tests can rely
* tests/init.sh (setup_): Initialize fail=0 before invoking mktempd_.
Ensure that IFS is defined initially.
(mktempd_): Remove fail=0 initialization; no longer needed.
---
tests/init.sh | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/tests/init.sh
This prevents a compilation failure on Solaris 8, GCC 4.4.2, with
configure --enable-gcc-warnings.
* src/who.c (MAXHOSTNAMELEN): Remove; no longer needed.
* src/pinky.c: Likewise.
---
src/pinky.c |4
src/who.c |4
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git
On 12/30/2010 01:24 PM, Eric Blake wrote:
If you like it, I'll
push to gnulib first and then synchronize coreutils to the latest.
Either order is fine, thanks, but we should try to keep them in sync.
I installed this so that coreutils will bootstrap from the
latest gnulib's implementation of ftoastr etc.
From 3292610bce67b331d7a99adc0171ed8b1b2f9b15 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Tue, 11 Jan 2011 17:52:40 -0800
Subject: [PATCH 1/2] build: update gnulib
On 01/24/11 10:31, Eric Blake wrote:
Hmm, it may still make sense to do both things - make it possible
to completely elide HAVE_RAW_DECL_* (this patch) for configure
built for a tarball, as well as to provide a configure option
(rather than the current ad-hoc approach of
make
I pushed this one as obvious:
From 7195a3a9775db6f249ebfaa7df4bf79e17421a3d Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Mon, 14 Feb 2011 21:05:18 -0800
Subject: [PATCH] uptime: omit unnecessary #if
* src/uptime.c (print_uptime): Omit unnecessary #if defined
On 07/08/11 10:27, Eric Blake wrote:
if O_NOATIME is 0, --noatime should be rejected as an outright
impossibility.
if O_NOATIME is non-zero, --noatime should enable FTS_NOATIME, but only
as a best-effort (that is, the option is silently ignored where the
kernel is too old),
If --noatime is
On 08/11/2011 11:28 AM, Paul Eggert wrote:
I'll look at coreutils shortly.
... and I discovered that coreutils was still using gettext 0.17 (!)
via autopoint, so it didn't pick up the gnulib patch (and it was missing
several other gnulib fixes since 0.17). I installed the
following
On 08/11/2011 06:49 PM, Eric Blake wrote:
I'm not sure if we should revert this part of your change.
Unfortunately if that part is reverted, then coreutils would lose
all gnulib fixes in the gettext area, due to the funny way that
'bootstrap' invokes autopoint. This includes not only the fix
On 09/07/11 02:49, Bruno Haible wrote:
-#include fcntl.h
+/* Write fcntl.h here, not fcntl.h, otherwise OSF/1 5.1 DTK cc
miscompiles
+ openat.c because that file has a preliminary #include fcntl.h. */
+#include fcntl.h
Thanks. Is a similar change needed to lib/open.c,
which plays the
On 09/07/11 00:21, Laurent TARRISSE wrote:
The 'bug' appeared on Linux, because dirname doesn't output the path when
several arguments are passed to it. :)
The same 'bug' will also appear on Solaris 10; its
dirname does the same thing as GNU/Linux's dirname.
I'm afraid you're fighting an
On 11/09/11 13:36, Ludovic Courtès wrote:
What about a patch along these lines?
I'd rather not hardwire assumptions about AIX into
the 'configure' code, so instead I installed the
following more-conservative patch, which I hope
fixes your problem.
fstatat: work with cross-compilation
Problem
On 11/09/11 16:42, Eric Blake wrote:
we also ought to guess yes on cygwin 1.7 and on Solaris 10 and newer, which
we also know work.
... which is why I was trying to avoid this issue. :-)
I'm not a fan of hardwiring this stuff in, as I
figure that people doing embedded cross-compilation
should
On 11/09/11 17:55, Bruno Haible wrote:
Paul Eggert wrote:
One possibility is to assume that AIX 7.1 is the only
target platform with that bug -- that would be easier
to maintain
Yes, this appears to be the case.
OK, let's go with that then. Or perhaps, a bit more
conservatively, we can
I pushed this:
Redirect with the shell command, not in a separate 'exec'.
Without this patch, Fedora 15 x86-64 /bin/sh (i.e., Bash 4.2.10)
complained about running out of file descriptors in the shell.
---
tests/misc/sort-continue |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
or later http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Mike Haertel and Paul Eggert.
+ ulimit -n 6
+ sort
++ seq 31
+ for i in '$(seq 31)'
+ echo 1
+ tee -a in
+ for i in '$(seq 31
On 11/15/11 07:29, abdallah clark wrote:
Maybe it's a manpower issue
We are short of people and time, yes. I've found your
comments to be helpful in pointing out places where the
--help output (man pages) could be clearer. We've fixed the SIZE sentence
and I'd like to go onto the next issue.
On 11/15/11 08:36, Jim Meyering wrote:
Undoing it seems best.
OK, done.
On 11/15/11 08:45, Voelker, Bernhard wrote:
-KB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T, P, E, Z,
Y.\n\
+KB (1000), K (1024), MB (1000KB), M (1024K), and so on for G, T, P, E, Z,
Y.\n\
That would be fine with me. (I find them equally confusing. :-)
On 01/04/12 14:30, Jim Meyering wrote:
You could form the symlink-free full name of the referent, abs_src
and then test same_name (abs_src, dst_name).
That doesn't sound right, since the symlink may resolve differently
after it's moved. For example:
$ ls -ldt lt ny d d/lt.new
drwxr-xr-x. 2
the assumption. I don't know if this'll fix the
problem on HP-UX, but it does fix a portability bug.
From 78f4bb60feed11a5241fec297d8250c1b11cc5b2 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Wed, 4 Jan 2012 16:04:38 -0800
Subject: [PATCH] test-posixtm: don't assume signed integer
On 01/06/12 02:14, Jim Meyering wrote:
The new quoting policy is inconsistent, since many diagnostics now use
quotes like this 'token', while quote (foo) still produces `foo' in
the C locale.
The idea is that Paolo's quotearg changes (see the thread at
On 01/13/2012, Geoff Clare wrote:
One problem with requiring Option 2A is that it requires du to use
much more memory for hierarchies where there are large numbers
of files with link count 1. This could be a problem for embedded
systems in particular.
The extra memory shouldn't be needed in
On 02/07/2012 05:49 AM, francky.l...@telenet.be wrote:
is there any way I could suppress the warning given by chmod +x?
You can suppress all warnings with the shell command:
chmod +x file 2/dev/null;:
This is usually not a good idea. The warnings are there
for a reason.
On 02/07/2012 12:10 PM, Filipus Klutiero wrote:
Size on disk
We don't know it's a disk drive; it might be
any storage device that contain a file system.
Perhaps a better shorthand string would be Allocation?
That's even shorter, and it conveys what's going on.
On 02/07/2012 07:59 AM, francky.l...@telenet.be wrote:
I was wondering wether I couldn't write something like
if [not on NTFS filesystem] then
chmod +x
No doubt you can write something like that.
I don't use NTFS, so I'm not a good source of advice
about the details.
Thanks for reviewing that. What a mess!
An odd thing is that the patch *did* fix things for
Fedora 15. Maybe its shell is busted? But that's a
different matter.
I think we can address this particular problem without
relying on a new coreutils feature, though the feature
you mention does sound
On 02/24/2012 04:53 AM, Ondrej Vasik wrote:
+@command{chmod} by default keeps the set-user-ID and set-group-ID bits
+of @var{mode} of a directory when the mode is specified as an octal digit,
+unless the mode length is 5 digits with leading double zero.
Wait a minute: 00755 works, but 000775
I think 'sort' by default uses 1/8 of physical memory.
It sounds like that calculation isn't working on your host;
if so, it'd be nice if you could dive into the code and see why.
On 02/24/2012 10:27 AM, Ondrej Vasik wrote:
Leading = probably makes sense, however the request in
https://bugzilla.redhat.com/show_bug.cgi?id=691466 was talking about
support for octal digits only
The original request was that chmod 0755 dir should clear
the setuid bits. We're not
The coauthors of this change are myself, Drew Kutilek, and James Wendt.
* tests/Makefile.am (TESTS): Add misc/sort-discrim.
* tests/misc/sort-discrim: New file, which tests a discriminator-based
implementation of 'sort'. Coreutils doesn't use this implementation
yet, but the test is useful
On 03/16/2012 04:03 AM, Pádraig Brady wrote:
Lots of tests were failing on this loan machine...
The proposed gnulib patch avoids the issue for me.
I proposed exactly that patch in January:
http://lists.gnu.org/archive/html/bug-gnulib/2012-01/msg00319.html
but Bruno explained that this is a
On 05/10/2012 01:10 AM, Jim Meyering wrote:
Filtering your patch through sed 's/^ / /'
was enough to undo the offending transformation.
Sorry about that. It's probably the recent upgrade
to Thunderbird 12.0.1 on my home desktop. I'll
have to look into why it's doing that, or just
give up and
c498519fcf4e4a2cc93c1ca75d0b263e215fc01a Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Mon, 11 Jun 2012 02:47:05 -0700
Subject: [PATCH] sort: by default, do not exceed 3/4 of physical memory
* src/sort.c (default_sort_size): Do not exceed 3/4 of total memory.
See Jeff Janes's bug report in
http
On 06/11/2012 03:02 AM, Paul Eggert wrote:
* src/sort.c (default_sort_size): Do not exceed 3/4 of total memory
Come to think of it, that patch is too conservative, as it
limits things to at most 3/8 of total memory. The 3/4 limit
should be applied after 'size' is halved, not before. Here's
/html/coreutils/2012-06/msg00018.html.,
while not reintroducing bug 10877. Jeff, can you please try this out in
your environment? It'd be nicer if it could be verified to work
there. Thanks.
From ad47c76273b84d64d1c612b2cc49e9679b187004 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
* doc/coreutils.texi: Use right amount of spacing after punctuation.
---
doc/coreutils.texi | 159 ++--
1 files changed, 80 insertions(+), 79 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 954a1f8..3c7f4e5 100644
---
On 07/10/2012 07:31 AM, Jeff Janes wrote:
Yes, that fixed the problem.
OK, thanks for checking; I pushed it into the coreutils
master on savannah.
On 07/12/2012 04:50 AM, Pádraig Brady wrote:
So how about we just change \n - \012.
That would mean we also need to change \ - \\
(otherwise the output would be ambiguous),
and at that point it might make sense to escape
space and tab consistently with the the lower
level interface.
On 07/12/2012 01:53 AM, Jim Meyering wrote:
I'd say grep, but we'd need more context to filter out false positives.
I'm afraid that grep is what I used, and yes,
it required some manual filtering.
On 09/04/2012 08:02 AM, Jim Meyering wrote:
I'm not 100% sold on the idea that that final unlinkat
call should be creating a dangling symlink (i.e., by removing
the directory to which s points).
But that's what rmdir() and the rmdir command
are supposed to do. That much, at least, is pretty
On 09/06/2012 05:12 AM, Paolo Bonzini wrote:
I consider shuf foo -o foo (on a read-write file) to be insecure.
Besides, it works by chance
It's not by chance. shuf is designed to let you
shuffle a file in-place, and is documented to work,
by analogy with sort -o foo foo. If we ever
change
If some other process is writing F
while I run 'sed -i F', F is not replaced atomically.
How not so?
For example:
echo ac f
sed -i 's/a/b/' f
sed -i 's/c/d/' f
wait
cat f
If 'sed' were truly atomic, then the output of this would
always be 'bd'. But it's not.
* tests/df/df-output.sh: For the test df -B1K --output=size,
do not assume that the file system size fits in 9 bytes; it
might be larger than that, so omit leading space. Also, use
portable 'sed' commands: POSIX says sed commands inside { } should
all end in newline.
---
tests/df/df-output.sh |
On 11/08/2012 11:36 PM, Jim Meyering wrote:
I saw failures on 2 of 3 make -j5 check runs on
an old 2-core F18/i686+SSD/ext4. But when I revert the last
two changes to gnulib's tests/nap.h, I saw 10 successes in a row,
so I'd revert those if I had more time now.
Feel free to revert them;
On 11/09/2012 01:50 AM, Bernhard Voelker wrote:
What about simplifying the first s/... to eliminate all blanks?
Yes, could do that, if someone has the energy
I pushed this hoping that it may help forestall questions about
why dd is so, ahem, *unusual*
* doc/coreutils.texi (dd invocation): Mention JCL.
---
doc/coreutils.texi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index
I pushed this:
* doc/coreutils.texi (Top): Sync from gnulib parse-datetime.texi menu.
---
doc/coreutils.texi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 60096af..45a4b3d 100644
--- a/doc/coreutils.texi
+++
On 05/12/2013 10:14 PM, Jim Meyering wrote:
I ran gcc's -fsanitize=address against coreutils, and two
sort tests failed due to buffer overruns. Both arose via
a bug in quotearg.c. Patch below. Two things remain to do:
1) find when the bug was introduced (before push)
2) address the
* tests/misc/cut-huge-range.sh (subtract_one): New string.
(CUT_MAX): Don't pass a too-large integer to 'expr'.
---
tests/misc/cut-huge-range.sh | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/tests/misc/cut-huge-range.sh b/tests/misc/cut-huge-range.sh
---
gnulib | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gnulib b/gnulib
index cda5c90..1233589 16
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit cda5c90820d55b4b1f52d6a6f5329a10668bd720
+Subproject commit 12335899d0089131d854aa1b074f0c4d841dff42
--
1.7.11.7
* configure.ac: If clang, add -Wno-format-extra-args and
-Wno-tautological-constant-out-of-range-compare.
* gl/lib/rand-isaac.c (ind):
* gl/lib/randread.c (readisaac):
* src/ls.c (dev_ino_push, dev_ino_pop):
* src/sort.c (buffer_linelim):
* src/system.h (is_nul):
* src/tail.c
On 05/27/2013 05:07 PM, Jim Meyering wrote:
+max_BUFSIZ=$(expr 256 '*' 1024)
+lim=$(expr $SIZE_MAX - $max_BUFSIZ)
Can't this code fail, due to overflow, on non-GMP hosts? See:
http://lists.gnu.org/archive/html/coreutils/2013-05/msg00060.html
and look for $SIZE_MAX.
On 05/27/2013 06:04 PM, Jim Meyering wrote:
+lim=$(echo $SIZE_MAX | subtract_one_)
+lim=$(expr $lim - $max_BUFSIZ)
Sorry, I don't see how this will work either.
It's common for a GMP-less expr to handle values
only up to SIZE_MAX / 2, and subtracting just 1
won't work around that problem.
On 12/02/2013 01:05 PM, Pádraig Brady wrote:
each project would have
to add LIB_CRYPTO_MD5 etc. to their list of libs similarly
to the coreutils patch I had inline in my previous mail.
Thanks for explaining.
I tried that for Emacs and came up with the patch
appended to this message.
On 12/03/2013 05:45 AM, Pádraig Brady wrote:
I'll probably do this in coreutils configure.ac before gl_INIT,
so as to at least set the default as coreutils wants and caters for,
and allowing users to --without-openssl if they want.
dnl Enable use of libcrypto by default
-openssl.m4 | 13 ++---
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 5d935ad..9688c32 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,14 @@
2013-12-07 Paul Eggert egg...@cs.ucla.edu
+ md5, sha1, sha256, sha512: add
Pádraig Brady wrote:
* m4/gl-openssl.m4 (gl_CRYPTO_CHECK): Don't empty LIB_CRYPTO
That would inherit LIB_CRYPTO from the environment, no?
It might be better to move the LIB_CRYPTO= into the
initialization code.
Also, is libgcrypt compatible with libcrypt with
respect to MD5, SHA512, etc.?
Pádraig Brady wrote:
Where would be best to initialize this?
Maybe m4_divert_once([DEFAULTS], [LIB_CRYPTO=])?
The libgcrypt replacement calling out to libcrypto seems to work.
tests pass anyway.
I assume you're preparing a
gnulib patch that would prefer libgcrypt to libcrypto, or
something
-- Sergey, what do
you think?
From 5bdd09b4b5246d852b63455f1d629f38be115bf9 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Wed, 26 Feb 2014 23:57:26 -0800
Subject: [PATCH 1/2] savedir: new symbol for fast-read version
* lib/savedir.h (SAVEDIR_SORT_FASTREAD): New symbol
Problem reported by Rich Burridge.
* src/stat.c [HAVE_GETATTRAT]: Include attr.h, sys/nvpair.h.
(print_statfs, print_stat, print_it):
Pass fd, too, for the benefit of get_birthtime.
All uses changed.
(get_birthtime): New function, for porting to Solaris 11.
(print_stat): Use it.
* configure.ac
+ else if (S_ISREG (st.st_mode))
+{
+ off_t fsize = st.st_size;
+ if (fsize 0 fsize ST_BLKSIZE (st) size fsize)
+i_size = fsize;
+}
This can be simplified. There's no need to worry about checking whether
st.st_size == 0 since the code would do the right thing
* doc/coreutils.texi: Add @documentencoding UTF-8.
---
doc/coreutils.texi | 1 +
1 file changed, 1 insertion(+)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 592f4a6..a6dd075 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -2,6 +2,7 @@
@c %**start of header
Pádraig Brady wrote:
I didn't notice any quoting changes in the generated info or pdf file at least.
I think it depends on the Texinfo version. I'm using texinfo 5.2, the
latest stable version.
UTF-8 should be used where possible these days.
Should 'make dist' check that the
Pádraig Brady wrote:
Are these checks backed up by corresponding replacement code?
Are these checks correct?
Why has glibc not been updated in the 7 years since the checks were added?
As I recall, this comes from an old dispute about what glibc should do when
asked to print
Pádraig Brady wrote:
3. Since glibc no longer crashes, and no-one has complained about
these edge cases of invalid numbers, just avoid this replacement altogether
but push for the improvement to output nan in these cases in glibc.
Thanks, I like this option the best.
On 12/16/2014 05:46 AM, Pádraig Brady wrote:
if (xstrtoul (optarg, NULL, 10, val, ) != LONGINT_OK
-|| MIN (INT_MAX, SIZE_MAX) val)
- error (EXIT_FAILURE, 0, _(%s: invalid number), optarg);
+|| (MIN (INT_MAX, SIZE_MAX) val (errno = EOVERFLOW)))
+
Update of bug #19546 (project coreutils):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #4:
This was fixed as
On 04/09/2015 11:20 AM, Andreas Grünbacher wrote:
Sounds like the Savannah server should be be checking that for all
its projects that use gnulib.
No, because some projects deliberately don't want this check. Emacs is
one (gnulib imports are copied into the Emacs repository), Tar is
another
Andreas Grünbacher wrote:
This behavior is discouraging testing; I find that quite annoying.
Me too. It's bitten me several times and I can never remember how to shut it
off. Perhaps we should remove that test from 'make check' and have a further
rule 'make checker' that is stronger than
I found one nit:
+AC_CHECK_HEADERS([linux/xattr.h])
+AC_CHECK_HEADERS([sys/xattr.h],
+ [AC_CHECK_FUNCS_ONCE([getxattr])])
This is missing _ONCE and non-ONCE calls, which doesn't work as
expected. Simplest fix is to replace AC_CHECK_FUNCS_ONCE with
AC_CHECK_FUNCS.
On 05/26/2015 01:53 PM, Andreas Gruenbacher wrote:
---
lib/acl-internal.c| 30 ++
This one is missing a patch to ChangeLog. Please put the commit message
into the ChangeLog. Also, please put the string Bug#20666 somewhere
into the commit message body and the ChangeLog (they should
* bootstrap.conf, src/base64.c, src/cat.c, src/cksum.c:
* src/head.c, src/md5sum.c, src/od.c, src/split.c, src/sum.c:
* src/tac.c, src/tail.c, src/tee.c, src/tr.c, src/wc.c:
Adjust to renaming of the xsetmode module to xbinary-io,
and of the xsetmode function to xset_binary_mode.
---
---
gnulib | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gnulib b/gnulib
index 87c456b..820fa6a 16
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit 87c456bf6fb9453144890f0941c118a49b20fda5
+Subproject commit 820fa6ad064bf3ba81dc9e2cd7fa2b98bb270902
--
2.9.3
This fixes a bug noted by Eric Blake. Code was using xfreopen to
change files to binary mode, but this fails for stdout when in
append mode. Such code should use xsetmode instead. This affects
only the port on platforms like MS-Windows which distiguish text
from binary I/O.
* bootstrap.conf
---
gnulib | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gnulib b/gnulib
index 4e6e16b..87c456b 16
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit 4e6e16b3f43ce96302b1e52e48730c1f15e18c14
+Subproject commit 87c456bf6fb9453144890f0941c118a49b20fda5
--
2.9.3
* doc/coreutils.texi (Options for date): Capitalize a sentence.
* tests/misc/date-debug.sh: Adjust --debug output to match
recent changes to Gnulib’s parse-datetime module.
---
doc/coreutils.texi | 2 +-
tests/misc/date-debug.sh | 132 +++
2
These were found by clang.
* gl/lib/rand-isaac.c (min):
* gl/lib/randint.c (shift_right):
* src/md5sum.c (algorithm):
Remove; unused.
---
gl/lib/rand-isaac.c | 7 ---
gl/lib/randint.c| 13 +++--
src/md5sum.c| 8 ++--
3 files changed, 5 insertions(+), 23 deletions(-)
* gl/modules/tempname.diff: Update to match current Gnulib.
---
gl/modules/tempname.diff | 11 ++-
gnulib | 2 +-
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/gl/modules/tempname.diff b/gl/modules/tempname.diff
index 05725c5..4aee47c 100644
---
remaining
tzdata-dependent tests should be reasonably stable, I would think.
From b6d68d90981d9ce747d5d87f4f4da3991b3ee82b Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date: Thu, 9 Mar 2017 23:59:05 -0800
Subject: [PATCH] tests: port to tzdb-2017a
Problem reported by
On 04/05/2017 01:17 PM, Christian Brauner wrote:
Oh, where can that information be gathered from? I looked up isatty() and
ttyname{_r}() in:
The Open Group Base Specifications Issue 7
IEEE Std 1003.1-2008, 2016 Edition
Copyright © 2001-2016 The IEEE and The Open Group
but couldn't find any
Kamil Dudka wrote:
Still not perfect. Now it produces false positives with --backup=existing:
Yes, I know that, but there's no easy way to change that without introducing a
race condition the other way. I thought it better to be conservative and reject
the (extremely unusual) case that you
with the race for quite some time.
From 929501623820b8d2e4995542ededf2eebbb32894 Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date: Tue, 1 Aug 2017 13:14:03 -0700
Subject: [PATCH] copy: go back to failing 'cp --backup a~ a'
Suggested by Kamil Dudka in:
http://lists.gnu.org/archiv
877260 Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date: Thu, 3 Aug 2017 13:44:53 -0700
Subject: [PATCH] copy: more-accurate warning about destruction
* src/copy.c (copy_internal):
* tests/cp/backup-is-src.sh, tests/mv/backup-is-src.sh:
Say "might destroy"
I found some subtle bugs in Gnulib fts.c, and created a test case that reliably
fails in reiserfs due to confusion with st_nlink. I added this test case to
Gnulib and fixed the bugs I found. As far as I can see, the only problems that
should affect findutils and coreutils are minor performance
1 - 100 of 3458 matches
Mail list logo
