Re: rebased patches?

[Jim Meyering]

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));