Update from Gnulib by running admin/merge-gnulib

* lib/sys-limits.h: New file.

doc/misc/texinfo.tex

@@ -3,7 +3,7 @@
 % Load plain if necessary, i.e., if running under initex.
 \expandafter\ifx\csname fmtname\endcsname\relax\input plain\fi
 %
-\def\texinfoversion{2025-07-15.21}
+\def\texinfoversion{2025-07-31.19}
 %
 % Copyright 1985, 1986, 1988, 1990-2025 Free Software Foundation, Inc.
 %
@@ -9634,7 +9634,10 @@ might help (with 'rm \jobname.?? \jobname.??s')%
 % Auto-number footnotes.  Otherwise like plain.
 \gdef\footnote{%
   \global\advance\footnoteno by \@ne
-  \edef\thisfootno{$^{\the\footnoteno}$}%
+  %
+  % Output for the footnote marker.  If we are immediately after another
+  % footnote, output a comma and small space first.
+  \edef\thisfootno{$^{\ifnum\lastpenalty=3 ,\mskip 1mu \fi\the\footnoteno}$}%
   %
   % In case the footnote comes at the end of a sentence, preserve the
   % extra spacing after we do the footnote number.
@@ -9643,19 +9646,25 @@ might help (with 'rm \jobname.?? \jobname.??s')%
   %
   % Remove inadvertent blank space before typesetting the footnote number.
   \unskip
+  %
+  % \scriptspace is 0.5pt by default and gives excessive space before the
+  % comma if we have multiple footnote markers in a row.
+  \bgroup\scriptspace=0pt
     \thisfootno\@sf
+  \egroup
   \dofootnote
 }%
 
-% Don't bother with the trickery in plain.tex to not require the
+% marker for immediately after a footnote marker
-% footnote text as a parameter.  Our footnotes don't need to be so general.
+\gdef\footnoteendmarker{\penalty3 }
-%
+
-% Oh yes, they do; otherwise, @ifset (and anything else that uses
+% Do not require the footnote text as a parameter; otherwise, @ifset
-% \parseargline) fails inside footnotes because the tokens are fixed when
+% (and anything else that uses \parseargline) fails inside footnotes
-% the footnote is read.  --karl, 16nov96.
+% because the tokens are fixed when the footnote is read.
 %
 \gdef\dofootnote{%
   \insert\footins\bgroup
+  \aftergroup\footnoteendmarker
   %
   % Nested footnotes are not supported in TeX, that would take a lot
   % more work.  (\startsavinginserts does not suffice.)
@@ -9686,14 +9695,14 @@ might help (with 'rm \jobname.?? \jobname.??s')%
   % Hang the footnote text off the number.  Use \everypar in case the
   % footnote extends for more than one paragraph.
   \everypar = {\hang}%
-  \textindent{\thisfootno}%
+  \textindent{$^{\the\footnoteno}$}%
   %
   % Don't crash into the line above the footnote text.  Since this
   % expands into a box, it must come within the paragraph, lest it
   % provide a place where TeX can split the footnote.
   \footstrut
   %
-  % Invoke rest of plain TeX footnote routine.
+  % Eat opening brace and invoke rest of plain TeX footnote routine.
   \futurelet\next\fo@t
 }
 }%end \catcode `\@=11

lib/copy-file-range.c

@@ -21,9 +21,22 @@
 #include <errno.h>
 
 #if defined __linux__ && HAVE_COPY_FILE_RANGE
+# include <linux/version.h>
 # include <sys/utsname.h>
+/* Although it can be dicey to use static checks for Linux kernel versions,
+   due to the dubious practice of building on newer kernels for older ones,
+   do it here anyway as the buggy kernels are rare (they are all EOLed)
+   and builders for them are unlikely to use the dubious practice.
+   Circa 2029 we should remove the old-kernel workarounds entirely.  */
+# if LINUX_VERSION_CODE < KERNEL_VERSION (5, 3, 0)
+#  define CHECK_LINUX_KERNEL_VERSION true
+# else
+#  define CHECK_LINUX_KERNEL_VERSION false
+# endif
 #endif
 
+#include "sys-limits.h"
+
 ssize_t
 copy_file_range (int infd, off_t *pinoff,
                  int outfd, off_t *poutoff,
@@ -31,32 +44,51 @@ copy_file_range (int infd, off_t *pinoff,
 {
 #undef copy_file_range
 
-#if defined __linux__ && HAVE_COPY_FILE_RANGE
+#if HAVE_COPY_FILE_RANGE
+  bool ok = true;
+
+# if CHECK_LINUX_KERNEL_VERSION
   /* The implementation of copy_file_range (which first appeared in
      Linux kernel release 4.5) had many issues before release 5.3
      <https://lwn.net/Articles/789527/>, so fail with ENOSYS for Linux
      kernels 5.2 and earlier.
 
-     This workaround, and the configure-time check for Linux, can be
+     This workaround can be removed when such kernels (released March
-     removed when such kernels (released March 2016 through September
+     2016 through September 2019) are no longer a consideration.
-     2019) are no longer a consideration.  As of January 2021, the
+     Although all such kernels have reached EOL, some distros use
-     furthest-future planned kernel EOL is December 2024 for kernel
+     older kernels.  For example, RHEL 8 uses kernel 4.18 and has an
-     release 4.19.  */
+     EOL of 2029.  */
 
-    static signed char ok;
+  static signed char kernel_ok;
-
+  if (! kernel_ok)
-    if (! ok)
     {
       struct utsname name;
       uname (&name);
       char *p = name.release;
-        ok = ((p[1] != '.' || '5' < p[0]
+      kernel_ok = ((p[1] != '.' || '5' < p[0]
                     || (p[0] == '5' && (p[3] != '.' || '2' < p[2])))
                    ? 1 : -1);
     }
 
-    if (0 < ok)
+  if (kernel_ok < 0)
+    ok = false;
+# endif
+
+  if (ok)
+    {
+#   if defined __GLIBC__ && ! (2 < __GLIBC__ + (43 <= __GLIBC_MINOR__))
+      /* Work around glibc bug 33245
+         <https://sourceware.org/bugzilla/show_bug.cgi?id=33245>.
+         This bug is present in glibc 2.42 (2025) and fixed in 2.43,
+         so this workaround, and the configure-time check for glibc,
+         can be removed once glibc 2.42 and earlier is no longer a
+         consideration.  Perhaps in 2040.  */
+      if (SYS_BUFSIZE_MAX < length)
+        length = SYS_BUFSIZE_MAX;
+# endif
+
       return copy_file_range (infd, pinoff, outfd, poutoff, length, flags);
+    }
 #endif
 
   /* There is little need to emulate copy_file_range with read+write,

lib/gnulib.mk.in

@@ -1799,6 +1799,8 @@ ifneq (,$(GL_COND_OBJ_COPY_FILE_RANGE_CONDITION))
 libgnu_a_SOURCES += copy-file-range.c
 endif
 
+EXTRA_DIST += sys-limits.h
+
 endif
 ## end   gnulib module copy-file-range
 

lib/sys-limits.h

@@ -0,0 +1,42 @@
+/* System call limits
+
+   Copyright 2018-2025 Free Software Foundation, Inc.
+
+   This file is free software: you can redistribute it and/or modify
+   it under the terms of the GNU Lesser General Public License as
+   published by the Free Software Foundation; either version 2.1 of the
+   License, or (at your option) any later version.
+
+   This file is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public License
+   along with this program.  If not, see <https://www.gnu.org/licenses/>.  */
+
+#ifndef _GL_SYS_LIMITS_H
+#define _GL_SYS_LIMITS_H
+
+#include <limits.h>
+
+/* Maximum number of bytes to read or write in a single system call.
+   This can be useful for system calls like sendfile on GNU/Linux,
+   which do not handle more than MAX_RW_COUNT bytes correctly.
+   The Linux kernel MAX_RW_COUNT is at least INT_MAX >> 20 << 20,
+   where the 20 comes from the Hexagon port with 1 MiB pages; use that
+   as an approximation, as the exact value may not be available to us.
+
+   Using this also works around a serious Linux bug before 2.6.16; see
+   <https://bugzilla.redhat.com/show_bug.cgi?id=612839>.
+
+   Using this also works around a Tru64 5.1 bug, where attempting
+   to read INT_MAX bytes fails with errno == EINVAL.  See
+   <https://lists.gnu.org/r/bug-gnu-utils/2002-04/msg00010.html>.
+
+   Using this is likely to work around similar bugs in other operating
+   systems.  */
+
+enum { SYS_BUFSIZE_MAX = INT_MAX >> 20 << 20 };
+
+#endif

m4/copy-file-range.m4

@@ -51,9 +51,8 @@ AC_DEFUN([gl_FUNC_COPY_FILE_RANGE],
       [Define to 1 if the function copy_file_range exists.])
 
     case $host_os in
-      linux*)
+      *-gnu* | gnu* | linux*)
-        # See copy-file-range.c comment re pre-5.3 Linux kernel bugs.
+        # See copy-file-range.c comment re glibc and Linux kernel bugs.
-        # We should be able to remove this hack in 2025.
         REPLACE_COPY_FILE_RANGE=1;;
     esac
   fi

m4/gnulib-comp.m4

@@ -1420,6 +1420,7 @@ AC_DEFUN([gl_FILE_LIST], [
   lib/strtol.c
   lib/strtoll.c
   lib/symlink.c
+  lib/sys-limits.h
   lib/sys_random.in.h
   lib/sys_select.in.h
   lib/sys_stat.in.h