bug#20936: suggestion for a 'wart-ish' extension off of 'sort'
I admit the ability to show a summary line might not bethe first thing you'd think a pure-sorting utility might do, but it would be awfully handy if sort had a 'Numeric sum' option (-N -- preferred '-s', but it's already taken) to go with the -h sorting: ala: du -sh *|sort -h|tail 6.0Mfirmware 6.7Mkernel 8.4Mtools 26M net 29M sound 30M Documentation 31M include 37M fs 128March 330Mdrivers --- vs. --- du -sh *|hsort -s|tail -12 6.0Mfirmware 6.7Mkernel 8.4Mtools 26M net 29M sound 30M Documentation 31M include 37M fs 128March 330Mdrivers - 649.4M TOTAL --- I'd donate the code for hsort, but its in perl -- I wrote it several years ago to do what 'sort -h' does, but also put in the option for a summary line -- handy companion for 'human numbers', which would otherwise take alot more typing (I think -- unless there's some hidden switch I don't know about).
bug#20936: suggestion for a 'wart-ish' extension off of 'sort'
Hi, On Tue, Jun 30, 2015 at 12:28:09AM -0700, Linda Walsh wrote: I admit the ability to show a summary line might not bethe first thing you'd think a pure-sorting utility might do, but it would be awfully handy if sort had a 'Numeric sum' option (-N -- preferred '-s', but it's already taken) to go with the -h sorting: ala: du -sh *|sort -h|tail Why not use 'du -shc * | sort -h | tail -n11'? The total produced by du will sort after all the individual parts. Thanks, Erik
bug#20775: cp -a -u destroys files after they are copied
Hello, the bug was observed on Linux this time. Unfortunately I was hit with the bug when backing up several large photo directories with hard-links to one target directory on an external drive. So it was not obvious for me at first, that something was going wrong. From my point of view (without looking at the source) it should be easy to repair by - not attempting to create a hard-link from a file to itself - not deleting a file that is about to be used as the source paramter of a hard-link to be created. best regards Steffen Zahn On Tue, Jun 30, 2015 at 9:02 AM L. A. Walsh coreut...@tlinx.org wrote: I think you'll find this was reported 3 years ago.. bug#10471: Severe or critical - deletes existing files and leaves nothing. (cp) https://lists.gnu.org/archive/html/bug-coreutils/2015-04/msg1.html Unfortunately it was closed it out w/the reason that it was a cygwin/windows-only -- which I disagreed with. I was told the cygwin dev would check it out and if it was in coreutils would move it back to active status (that was 3+ years ago). On 6/8/2015 9:18 PM, Steffen Zahn wrote: Hello, I found that the cp command acts sub-optimal when copying hard-linked files of the same name from several directories to one target directory, it first copies the files then removes them. I cannot see how that can be the intended behaviour. Please fix this. best regards Steffen Zahn sz@gandalf:~ $ cd /tmp sz@gandalf:/tmp $ mkdir 1 2 3 sz@gandalf:/tmp $ touch 1/a sz@gandalf:/tmp $ ln 1/a 2/ sz@gandalf:/tmp $ ls -li 1 2 1: total 0 262424 -rw-r--r-- 2 sz sz 0 Jun 9 06:10 a 2: total 0 262424 -rw-r--r-- 2 sz sz 0 Jun 9 06:10 a sz@gandalf:/tmp $ cp -a -u --verbose 1/* 2/* 3/ '1/a' - '3/a' removed '3/a' cp: cannot create hard link '3/a' to '3/a': No such file or directory sz@gandalf:/tmp $ cp --version
bug#20936: suggestion for a 'wart-ish' extension off of 'sort'
Hi, On Tue, Jun 30, 2015 at 02:35:17AM -0700, Linda Walsh wrote: On 6/30/2015 12:46 AM, Erik Auerswald wrote: du -sh *|sort -h|tail Why not use 'du -shc * | sort -h | tail -n11'? The total produced by du will sort after all the individual parts. Good idea -- didn't know about '-c', but two things, 1 troubling, the other a confusion. If you have a dir named 'total' it can be slightly confusing: You'll always know that the last total is the total of the above. ;-) Ishtar:/tmp/dutest du -shc * |sort -h|tail 1.5Msperl,v 3.6Mtotal 5.0Mtotal Ishtar:/tmp/dutest du -sh * |hsort -s|tail 1.5Msperl,v 3.6Mtotal - 5.1MTOTAL But more a more obvious problem is 'du -shc' seems to be coming up with the wrong number -- i.e. 1.5+3.6 = 5.1, not 5.0. That are probably rounding errors avoided by du, that hsort cannot avoid anymore. Thanks, Erik
[PATCH] tests: avoid false failure on FreeBSD systems
* tests/misc/stty.sh: FreeBSD returns ENOTTY for the TIOCEXT ioctl, so just avoid this option for now. --- tests/misc/stty.sh | 4 1 file changed, 4 insertions(+) diff --git a/tests/misc/stty.sh b/tests/misc/stty.sh index 5c25755..5e39b72e 100755 --- a/tests/misc/stty.sh +++ b/tests/misc/stty.sh @@ -57,6 +57,10 @@ for opt in $options; do cstopb|crtscts|cdtrdsr|icanon) continue;; esac + # This is listed as supported on FreeBSD + # but the ioctl returns ENOTTY. + test $opt = extproc continue + stty $opt || fail=1 # Likewise, 'stty -cread' would fail, so skip that, too. -- 2.4.1
Pretest - more virtual machines of free OSes (OT)
Hello, For portability testing, I've added more virtual images to the Pretest project ( http://pretest.nongnu.org/ ): GNU Hurd 0.6, FreeBSD 10.1, Debian/kFreeBSD 7 OpenBSD 5.7, Debian 8.1, Fedora 22, Ubuntu 15.04, OpenIndiana 2015-03 Hipster. For quicker and simpler usage, I've created two webpages to show the needed command line to download and run each VM, under QEMU: http://pretest.nongnu.org/command-line-qemu.html and LibVirt: http://pretest.nongnu.org/command-line-libvirt.html Comments welcome, please send to pretest-us...@nongnu.org . regards, - assaf
bug#20936: suggestion for a 'wart-ish' extension off of 'sort'
On 6/30/2015 3:51 AM, Erik Auerswald wrote: Ishtar:/tmp/dutest du -shc * |sort -h|tail 1.5Msperl,v 3.6Mtotal 5.0Mtotal Ishtar:/tmp/dutest du -sh * |hsort -s|tail 1.5Msperl,v 3.6Mtotal - 5.1MTOTAL But more a more obvious problem is 'du -shc' seems to be coming up with the wrong number -- i.e. 1.5+3.6 = 5.1, not 5.0. That are probably rounding errors avoided by du, that hsort cannot avoid anymore. --- 1) I think you're right, but 2) it still looks odd to see 1.5+3.6=5.0 and not 5.1
bug#20775: cp -a -u destroys files after they are copied
Steffen Zahn wrote: it should be easy to repair Really? Without significantly affecting performance in the usual case? Let's see a patch.
bug#20923: mgetgroups.c vs getgrouplist warning on OS X
Jim Meyering wrote:
same result as before:
OK, let's give up on this approach and try something more direct. I installed
the attached patch; does it work on OS X?
From b1a1450d454698a765a625804fe336305209c696 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Tue, 30 Jun 2015 09:32:07 -0700
Subject: [PATCH] mgetgroups: port to strict OS X
The previous fix wasn't working, so use a bigger hammer (Bug#20923).
* lib/mgetgroups.c: Ignore -Wpointer-sign diagnostics.
(getgrouplist_gids) [HAVE_GETGROUPLIST]: Remove. All uses removed.
* m4/mgetgroups.m4 (gl_MGETGROUPS): Revert recent changes.
---
ChangeLog| 8
lib/mgetgroups.c | 14 +++---
m4/mgetgroups.m4 | 35 +--
3 files changed, 16 insertions(+), 41 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index cb6ca08..37120cd 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2015-06-30 Paul Eggert egg...@cs.ucla.edu
+
+ mgetgroups: port to strict OS X
+ The previous fix wasn't working, so use a bigger hammer (Bug#20923).
+ * lib/mgetgroups.c: Ignore -Wpointer-sign diagnostics.
+ (getgrouplist_gids) [HAVE_GETGROUPLIST]: Remove. All uses removed.
+ * m4/mgetgroups.m4 (gl_MGETGROUPS): Revert recent changes.
+
2015-06-29 Paul Eggert egg...@cs.ucla.edu
mgetgroups: port to strict OS X
diff --git a/lib/mgetgroups.c b/lib/mgetgroups.c
index dd0c7a5..6acb019 100644
--- a/lib/mgetgroups.c
+++ b/lib/mgetgroups.c
@@ -33,6 +33,12 @@
#include getugroups.h
#include xalloc-oversized.h
+/* Work around an incompatibility of OS X 10.11: getgrouplist
+ accepts int *, not gid_t *, and int and gid_t differ in sign. */
+#if 4 __GNUC__ + (3 = __GNUC_MINOR__)
+# pragma GCC diagnostic ignored -Wpointer-sign
+#endif
+
static gid_t *
realloc_groupbuf (gid_t *g, size_t num)
{
@@ -64,11 +70,6 @@ mgetgroups (char const *username, gid_t gid, gid_t **groups)
gid_t *g;
#if HAVE_GETGROUPLIST
-# if HAVE_GETGROUPLIST_WITH_INT
-# define getgrouplist_gids(g) ((int *) (g))
-# else
-# define getgrouplist_gids(g) (g)
-# endif
/* We prefer to use getgrouplist if available, because it has better
performance characteristics.
@@ -92,8 +93,7 @@ mgetgroups (char const *username, gid_t gid, gid_t **groups)
int last_n_groups = max_n_groups;
/* getgrouplist updates max_n_groups to num required. */
- ng = getgrouplist (username, gid, getgrouplist_gids (g),
- max_n_groups);
+ ng = getgrouplist (username, gid, g, max_n_groups);
/* Some systems (like Darwin) have a bug where they
never increase max_n_groups. */
diff --git a/m4/mgetgroups.m4 b/m4/mgetgroups.m4
index 5747148..42b5cf8 100644
--- a/m4/mgetgroups.m4
+++ b/m4/mgetgroups.m4
@@ -1,4 +1,4 @@
-#serial 7
+#serial 5
dnl Copyright (C) 2007-2015 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -6,38 +6,5 @@ dnl with or without modifications, as long as this notice is preserved.
AC_DEFUN([gl_MGETGROUPS],
[
- AC_CHECK_HEADERS_ONCE([grp.h])
AC_CHECK_FUNCS_ONCE([getgrouplist])
- if test $ac_cv_func_getgrouplist = yes; then
-AC_CACHE_CHECK([for getgrouplist with int signature],
- [gl_cv_getgrouplist_with_int],
- [gl_cv_getgrouplist_with_int=no
- gl_save_c_werror_flag=$ac_c_werror_flag
- ac_c_werror_flag=yes
- AC_COMPILE_IFELSE(
- [AC_LANG_PROGRAM(
-[[#if HAVE_GRP_H
- #include grp.h
- #endif
- int groups[1];
- int ngroups = 1;
-]],
-[[return - getgrouplist (root, 0, groups, ngroups);]])],
- [],
- [AC_COMPILE_IFELSE(
- [AC_LANG_PROGRAM(
- [[#if HAVE_GRP_H
- #include grp.h
-#endif
-int groups[sizeof (gid_t) == sizeof (int) ? 1 : -1];
-int ngroups = 1;
- ]],
- [[return - getgrouplist (root, 0, groups, ngroups);]])],
-[gl_cv_getgrouplist_with_int=yes])])
- ac_c_werror_flag=$gl_save_c_werror_flag])
-if test $gl_cv_getgrouplist_with_int = yes; then
- AC_DEFINE([HAVE_GETGROUPLIST_WITH_INT], 1,
-[Define to 1 if getgrouplist accepts and returns int and not gid_t.])
-fi
- fi
])
--
2.1.0
bug#20936: suggestion for a 'wart-ish' extension off of 'sort'
Hello,
On 06/30/2015 03:28 AM, Linda Walsh wrote:
I admit the ability to show a summary line might not bethe first
thing you'd think a pure-sorting utility might do, but it would be
awfully handy if sort had a 'Numeric sum' option (-N -- preferred
'-s', but it's already taken) to go with the -h sorting:
...
du -sh *|sort -h|tail
A slightly different approach would be to defer the human size to later,
and enable to do any calculation you want manually, then convert to human sizes with
numfmt:
du -s * \
| sort -n \
| awk '{ sum+=$1 ; print } END { print sum, Total }' \
| numfmt --to=iec
One more thing: instead of 'du -s *', perhaps 'du -d1' would work better
(depending on your needs), as it will print sizes used only by directories.
- assaf
bug#20923: mgetgroups.c vs getgrouplist warning on OS X
On Tue, Jun 30, 2015 at 9:36 AM, Paul Eggert egg...@cs.ucla.edu wrote: Jim Meyering wrote: same result as before: OK, let's give up on this approach and try something more direct. I installed the attached patch; does it work on OS X? Perfect. I made latest coreutils use latest from gnulib, and now it all compiles warning-free there with --enable-gcc-warnings and gcc-6.x Thank you!
bug#20936: suggestion for a 'wart-ish' extension off of 'sort'
2015-06-30 13:05:38 -0400, Assaf Gordon: [...] One more thing: instead of 'du -s *', perhaps 'du -d1' would work better (depending on your needs), as it will print sizes used only by directories. Yes, and it will also include hidden files/dirs and won't have problems with filenames starting with -. Add -a if you also want non-directory files. -- Stephane
Re: Leap Second 2015-06-30 23:59:60 UTC
Bob Proulx bob-5cAygf9QrE/qt0dzr+a...@public.gmane.org writes: Hmm... I don't know. Should this work? No. POSIX doesn't have leap seconds. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Leap Second 2015-06-30 23:59:60 UTC
Hmm... I don't know. Should this work? I admit to being confused here. $ date -u -d '2015-06-30 23:59:60 UTC' date: invalid date ‘2015-06-30 23:59:60 UTC’ $ date -R -d '2015-06-30 23:59:59 UTC + 1 second' Tue, 30 Jun 2015 18:00:00 -0600 I guess we have a little over three hours to find out! :-) Bob
bug#20936: suggestion for a 'wart-ish' extension off of 'sort'
2015-06-30 12:51:02 +0200, Erik Auerswald: [...] But more a more obvious problem is 'du -shc' seems to be coming up with the wrong number -- i.e. 1.5+3.6 = 5.1, not 5.0. That are probably rounding errors avoided by du, that hsort cannot avoid anymore. [...] Also, du -c gives you the cumulative usage (think of hard links that need to be counted once), not the sum of the above. -- Stephane
Re: new snapshot available: coreutils-8.23.237-eff51
On 29/06/15 00:47, Jim Meyering wrote:
On Sun, Jun 28, 2015 at 3:08 PM, Pádraig Brady p...@draigbrady.com wrote:
On 28/06/15 21:01, Jim Meyering wrote:
From 8fc96e0a280211e7cdf0da5b685c1ec6b7668f78 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@fb.com
Date: Sun, 28 Jun 2015 10:17:57 -0700
Subject: [PATCH 1/2] maint: factor.c: touch up preceding change
* src/factor.c (print_factors_single): Add a const attribute.
Make n_out a more faithful count of output bytes.
---
src/factor.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/factor.c b/src/factor.c
index 60cf898..5b73c90 100644
--- a/src/factor.c
+++ b/src/factor.c
@@ -2364,9 +2364,9 @@ print_factors_single (uintmax_t t1, uintmax_t t0)
{
char buf[INT_BUFSIZE_BOUND (uintmax_t)];
putchar (' ');
-char *umaxstr = umaxtostr (factors.p[j], buf);
+char const *umaxstr = umaxtostr (factors.p[j], buf);
fputs (umaxstr, stdout);
-n_out += strlen (umaxstr) + 1;
+n_out += 1 + strlen (umaxstr) + 1;
Is the extra 1 really required?
The trailing one was there to cater for the putchar().
In a sense, it's not required... in that it doesn't really make
a difference if we're off-by-1-byte-per-line when deciding whether
to flush.
I thought the trailing + 1 was for the fputs-added newline,
so added the preceding 1 + for the putchar.
The new tests/misc/factor-parallel.sh in this area was failing
on FreeBSD (derived) systems where PIPE_BUF = 512 is significant.
The attached patch rewrites this code and implements the line buffering
internally to factor, and with that the test passes on all systems.
cheers,
Pádraig.
From 8296088abdadf176cc69e6d814834a6265335b67 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Tue, 30 Jun 2015 06:58:57 +0100
Subject: [PATCH] factor: ensure atomic output through pipes
The new tests/misc/factor-parallel.sh test was
seen to fail on FreeBSD (derived) systems, which was
due to split(1) --filter reading partial lines
through pipes, as factor(1) was writing a little
over PIPE_BUF each time.
* src/factor.c (lbuf): A new structure to internally buffer lines.
(lbuf_alloc): A new function to allocate enough at program start.
(lbuf_putint): A new function to buffer a uintmax_t.
(lbuf_flush): A new function to write directly to standard output.
(lbuf_putc): A new function to buffer a character and if enough
lines are buffered, then output complete lines = PIPE_BUF,
and continue to buffer the rest.
(main): Call the internal buffer allocator, and register
the final flush from the internal buffer at program exit.
---
src/factor.c | 122 ++-
1 file changed, 96 insertions(+), 26 deletions(-)
diff --git a/src/factor.c b/src/factor.c
index 60cf898..1d7d7c8 100644
--- a/src/factor.c
+++ b/src/factor.c
@@ -98,6 +98,7 @@
#include system.h
#include error.h
+#include full-write.h
#include quote.h
#include readtokens.h
#include xstrtol.h
@@ -2323,7 +2324,92 @@ strto2uintmax (uintmax_t *hip, uintmax_t *lop, const char *s)
return err;
}
-static size_t n_out; /* How much data we've written to stdout. */
+/* Structure and routines for buffering and outputting full lines,
+ to support parallel operation efficiently. */
+static struct lbuf_
+{
+ char *buf;
+ char *end;
+} lbuf;
+
+/* 512 is chosen to give good performance,
+ and also is the max guaranteed size that
+ consumers can read atomically through pipes.
+ Also it's big enough to cater for max line length
+ even with 128 bit uintmax_t. */
+#define FACTOR_PIPE_BUF 512
+
+static void
+lbuf_alloc (void)
+{
+ if (lbuf.buf)
+return;
+
+ /* Double to ensure enough space for
+ previous numbers + next number. */
+ lbuf.buf = xmalloc (FACTOR_PIPE_BUF * 2);
+ lbuf.end = lbuf.buf;
+}
+
+/* Write complete LBUF to standard output. */
+static void
+lbuf_flush (void)
+{
+ size_t size = lbuf.end - lbuf.buf;
+ if (full_write (STDOUT_FILENO, lbuf.buf, size) != size)
+error (EXIT_FAILURE, errno, %s, _(write error));
+ lbuf.end = lbuf.buf;
+}
+
+/* Add a character C to LBUF and if it's a newline
+ and enough bytes are already buffered,
+ then write atomically to standard output. */
+static void
+lbuf_putc (char c)
+{
+ *lbuf.end++ = c;
+
+ if (c == '\n')
+{
+ size_t buffered = lbuf.end - lbuf.buf;
+
+ if (buffered = FACTOR_PIPE_BUF)
+{
+ /* Write output in = PIPE_BUF chunks
+ so consumers can read atomically. */
+ char const *tend = lbuf.end;
+
+ /* Since a umaxint_t's factors must fit in 512
+ we're guaranteed to find a newline here. */
+ char *tlend = lbuf.buf + FACTOR_PIPE_BUF;
+ while (*--tlend != '\n');
+ tlend++;
+
+ lbuf.end = tlend;
+ lbuf_flush ();
+
+ /* Buffer the remainder. */
+ memcpy (lbuf.buf, tlend,
bug#20775: cp -a -u destroys files after they are copied
I think you'll find this was reported 3 years ago.. bug#10471: Severe or critical - deletes existing files and leaves nothing. (cp) https://lists.gnu.org/archive/html/bug-coreutils/2015-04/msg1.html Unfortunately it was closed it out w/the reason that it was a cygwin/windows-only -- which I disagreed with. I was told the cygwin dev would check it out and if it was in coreutils would move it back to active status (that was 3+ years ago). On 6/8/2015 9:18 PM, Steffen Zahn wrote: Hello, I found that the cp command acts sub-optimal when copying hard-linked files of the same name from several directories to one target directory, it first copies the files then removes them. I cannot see how that can be the intended behaviour. Please fix this. best regards Steffen Zahn sz@gandalf:~ $ cd /tmp sz@gandalf:/tmp $ mkdir 1 2 3 sz@gandalf:/tmp $ touch 1/a sz@gandalf:/tmp $ ln 1/a 2/ sz@gandalf:/tmp $ ls -li 1 2 1: total 0 262424 -rw-r--r-- 2 sz sz 0 Jun 9 06:10 a 2: total 0 262424 -rw-r--r-- 2 sz sz 0 Jun 9 06:10 a sz@gandalf:/tmp $ cp -a -u --verbose 1/* 2/* 3/ '1/a' - '3/a' removed '3/a' cp: cannot create hard link '3/a' to '3/a': No such file or directory sz@gandalf:/tmp $ cp --version
bug#20936: suggestion for a 'wart-ish' extension off of 'sort'
On 6/30/2015 12:46 AM, Erik Auerswald wrote: du -sh *|sort -h|tail Why not use 'du -shc * | sort -h | tail -n11'? The total produced by du will sort after all the individual parts. Good idea -- didn't know about '-c', but two things, 1 troubling, the other a confusion. If you have a dir named 'total' it can be slightly confusing: Ishtar:/tmp/dutest du -shc * |sort -h|tail 1.5Msperl,v 3.6Mtotal 5.0Mtotal Ishtar:/tmp/dutest du -sh * |hsort -s|tail 1.5Msperl,v 3.6Mtotal - 5.1MTOTAL But more a more obvious problem is 'du -shc' seems to be coming up with the wrong number -- i.e. 1.5+3.6 = 5.1, not 5.0. In my original example, it's off by more: Ishtar:linux/linux-4.1.0 du -sch *|sort -h|tail 6.7Mkernel 8.4Mtools 26M net 29M sound 30M Documentation 31M include 37M fs 128March 330Mdrivers 645Mtotal Ishtar:linux/linux-4.1.0 du -sh *|hsort -s|tail 8.4Mtools 26M net 29M sound 30M Documentation 31M include 37M fs 128March 330Mdrivers - 649.4M TOTAL
[PATCH] numfmt: increase precision on 32 bit FreeBSD
* m4/jm-macros.m4 (HAVE_FPSETPREC): Define if needed. * src/numfmt.c (main): Call fpsetprec() if needed. Fixes large-15 and large-16 test failures on 32 bit FreeBSD. --- m4/jm-macros.m4 | 15 +++ src/numfmt.c| 9 + 2 files changed, 24 insertions(+) diff --git a/m4/jm-macros.m4 b/m4/jm-macros.m4 index 79f124b..51c533a 100644 --- a/m4/jm-macros.m4 +++ b/m4/jm-macros.m4 @@ -165,6 +165,21 @@ AC_DEFUN([coreutils_MACROS], LIBS=$ac_seq_save_LIBS ]) + + # See is fpsetprec() required to use extended double precision + # This is needed on 32 bit FreeBSD to give accurate conversion of: + # `numfmt 9223372036854775808` + AC_TRY_LINK([#include ieeefp.h], +[#ifdef __i386__ + fpsetprec(FP_PE); + #else + # error not required on 64 bit + #endif +], [ac_have_fpsetprec=yes], [ac_have_fpsetprec=no]) + if test $ac_have_fpsetprec = yes ; then +AC_DEFINE([HAVE_FPSETPREC], 1, [whether fpsetprec is present and required]) + fi + AC_REQUIRE([AM_LANGINFO_CODESET]) # Accept configure options: --with-tty-group[=GROUP], --without-tty-group diff --git a/src/numfmt.c b/src/numfmt.c index e58972b..35c5c5b 100644 --- a/src/numfmt.c +++ b/src/numfmt.c @@ -32,6 +32,10 @@ #include gl_linked_list.h #include gl_xlist.h +#if HAVE_FPSETPREC +# include ieeefp.h +#endif + /* The official name of this program (e.g., no 'g' prefix). */ #define PROGRAM_NAME numfmt @@ -1574,6 +1578,11 @@ main (int argc, char **argv) bindtextdomain (PACKAGE, LOCALEDIR); textdomain (PACKAGE); +#if HAVE_FPSETPREC + /* Enabled extended precision if needed. */ + fpsetprec (FP_PE); +#endif + decimal_point = nl_langinfo (RADIXCHAR); if (decimal_point == NULL || strlen (decimal_point) == 0) decimal_point = .; -- 2.4.1
[PATCH] numfmt: increase precision on 32 bit FreeBSD
* m4/jm-macros.m4 (HAVE_FPSETPREC): Define if needed. * src/numfmt.c (main): Call fpsetprec() if needed. Fixes large-15 and large-16 test failures on 32 bit FreeBSD. --- m4/jm-macros.m4 | 15 +++ src/numfmt.c| 9 + 2 files changed, 24 insertions(+) diff --git a/m4/jm-macros.m4 b/m4/jm-macros.m4 index 79f124b..51c533a 100644 --- a/m4/jm-macros.m4 +++ b/m4/jm-macros.m4 @@ -165,6 +165,21 @@ AC_DEFUN([coreutils_MACROS], LIBS=$ac_seq_save_LIBS ]) + + # See is fpsetprec() required to use extended double precision + # This is needed on 32 bit FreeBSD to give accurate conversion of: + # `numfmt 9223372036854775808` + AC_TRY_LINK([#include ieeefp.h], +[#ifdef __i386__ + fpsetprec(FP_PE); + #else + # error not required on 64 bit + #endif +], [ac_have_fpsetprec=yes], [ac_have_fpsetprec=no]) + if test $ac_have_fpsetprec = yes ; then +AC_DEFINE([HAVE_FPSETPREC], 1, [whether fpsetprec is present and required]) + fi + AC_REQUIRE([AM_LANGINFO_CODESET]) # Accept configure options: --with-tty-group[=GROUP], --without-tty-group diff --git a/src/numfmt.c b/src/numfmt.c index e58972b..35c5c5b 100644 --- a/src/numfmt.c +++ b/src/numfmt.c @@ -32,6 +32,10 @@ #include gl_linked_list.h #include gl_xlist.h +#if HAVE_FPSETPREC +# include ieeefp.h +#endif + /* The official name of this program (e.g., no 'g' prefix). */ #define PROGRAM_NAME numfmt @@ -1574,6 +1578,11 @@ main (int argc, char **argv) bindtextdomain (PACKAGE, LOCALEDIR); textdomain (PACKAGE); +#if HAVE_FPSETPREC + /* Enabled extended precision if needed. */ + fpsetprec (FP_PE); +#endif + decimal_point = nl_langinfo (RADIXCHAR); if (decimal_point == NULL || strlen (decimal_point) == 0) decimal_point = .; -- 2.4.1
RE: Leap Second 2015-06-30 23:59:60 UTC
Date: Tue, 30 Jun 2015 14:40:17 -0600 From: b...@proulx.com To: coreutils@gnu.org Subject: Leap Second 2015-06-30 23:59:60 UTC Hmm... I don't know. Should this work? I admit to being confused here. $ date -u -d '2015-06-30 23:59:60 UTC' date: invalid date ‘2015-06-30 23:59:60 UTC’ $ date -R -d '2015-06-30 23:59:59 UTC + 1 second' Tue, 30 Jun 2015 18:00:00 -0600 I guess we have a little over three hours to find out! :-) Bob There is a leap second every 18 months on average. Can't you test it by turning off ntp and setting the system date just before one of the recent leap seconds? The last leap second was added at 23:59:60 UTC on June 30, 2012. https://en.wikipedia.org/wiki/Leap_second http://www.timeanddate.com/time/leapseconds.html William
