[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rebased patches?
From: |
Jim Meyering |
Subject: |
Re: rebased patches? |
Date: |
Tue, 17 Jun 2008 10:07:55 +0200 |
Bo Borgerson <address@hidden> wrote:
> I've pushed a version of the sort branch that contains the following
> updates:
>
> 1. Try to minimize changes to translatable strings
> 2. Improve diagnostic messages for files0-from edge-cases
> 3. Use the new standardized files0-from test script format
> 4. Avoid use of the '>' operator
> 5. Follow the log message summary template in HACKING
Hi Bo,
Thanks for doing that.
I've made the following changes (wording, scoping,
avoid-sprintf-when-possible, code-aesthetics), and expect
to squash them into yours and push the result later today.
diff --git a/NEWS b/NEWS
index 2fc676e..7b1df75 100644
--- a/NEWS
+++ b/NEWS
@@ -25,7 +25,7 @@ GNU coreutils NEWS -*-
outline -*-
sort accepts a new option --batch-size=NMERGE, where NMERGE
represents the maximum number of inputs that will be merged at once.
- When more than NMERGE inputs are present temporary files are used.
+ When more than NMERGE inputs are present, sort uses temporary files.
** Bug fixes
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index c4a6c9c..f7b9e78 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -3809,8 +3809,9 @@ Example: To sort on the second field, use
@option{--key=2,2}
@cindex number of inputs to merge, nmerge
Merge at most @var{nmerge} inputs at once.
-If more than @var{nmerge} inputs are to be merged, then temporary files
-will be used.
+When @command{sort} has to merge more than @var{nmerge} inputs,
+it merges them in groups of @var{nmerge}, saving the result in
+a temporary file, which is then used as an input in a subsequent merge.
A large value of @var{nmerge} may improve merge performance and decrease
temporary storage utilization at the expense of increased memory usage
@@ -3821,8 +3822,9 @@ merge performance.
The value of @var{nmerge} must be at least 2.
The value of @var{nmerge} may be bounded by a resource limit for open
-file descriptors. Try @samp{ulimit -n} to check for such a limit. If
-the value of @var{nmerge} exceeds this limit, then @command{sort} will
+file descriptors. Try @samp{ulimit -n} or @samp{getconf OPEN_MAX} to
+to display the limit for a particular system.
+If the value of @var{nmerge} exceeds this limit, then @command{sort} will
issue a warning to standard error and exit with a nonzero status.
@item -o @var{output-file}
diff --git a/src/sort.c b/src/sort.c
index 2bc3524..1393521 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -1077,7 +1077,6 @@ specify_nmerge (int oi, char c, char const *s)
uintmax_t n;
struct rlimit rlimit;
unsigned int max_nmerge = (unsigned int) MAX_NMERGE;
- char max_nmerge_buf[INT_BUFSIZE_BOUND (unsigned int)];
enum strtol_error e = xstrtoumax (s, NULL, 10, &n, NULL);
/* Try to find out how many file descriptors we'll be able
@@ -1089,7 +1088,9 @@ specify_nmerge (int oi, char c, char const *s)
if (e == LONGINT_OK)
{
nmerge = n;
- if (nmerge == n)
+ if (nmerge != n)
+ e = LONGINT_OVERFLOW;
+ else
{
if (nmerge < 2)
{
@@ -1113,18 +1114,14 @@ specify_nmerge (int oi, char c, char const *s)
return;
}
}
- else
- e = LONGINT_OVERFLOW;
}
if (e == LONGINT_OVERFLOW)
{
-
- sprintf (max_nmerge_buf, "%u", max_nmerge);
-
+ char max_nmerge_buf[INT_BUFSIZE_BOUND (unsigned int)];
+ uinttostr (max_nmerge, max_nmerge_buf);
error (0, 0, _("--%s argument %s too large"),
long_options[oi].name, quote(s));
-
error (SORT_FAILURE, 0,
_("maximum --%s argument with current rlimit is %s"),
long_options[oi].name, quote (max_nmerge_buf));