doc: Document the *-ieee modules

[Bruno Haible via Gnulib discussion list]

This patch documents the *-ieee modules.


2024-12-26  Bruno Haible  

doc: Document the *-ieee modules.
* doc/posix-functions/cbrt.texi: Mention the cbrt-ieee module.
* doc/posix-functions/cbrtf.texi: Mention the cbrtf-ieee module.
* doc/posix-functions/exp.texi: Mention the exp-ieee module.
* doc/posix-functions/exp2.texi: Mention the exp2-ieee module.
* doc/posix-functions/exp2f.texi: Mention the exp2f-ieee module.
* doc/posix-functions/expf.texi: Mention the expf-ieee module.
* doc/posix-functions/expl.texi: Mention the expl-ieee module.
* doc/posix-functions/expm1l.texi: Mention the expm1l-ieee module.
* doc/posix-functions/fabs.texi: Mention the fabs-ieee module.
* doc/posix-functions/fabsf.texi: Mention the fabsf-ieee module.
* doc/posix-functions/fabsl.texi: Mention the fabsl-ieee module.
* doc/posix-functions/fma.texi: Mention the fma-ieee module.
* doc/posix-functions/fmaf.texi: Mention the fmaf-ieee module.
* doc/posix-functions/fmal.texi: Mention the fmal-ieee module.
* doc/posix-functions/frexp.texi: Mention the frexp-ieee module.
* doc/posix-functions/frexpf.texi: Mention the frexpf-ieee module.
* doc/posix-functions/frexpl.texi: Mention the frexpl-ieee module.
* doc/posix-functions/ldexp.texi: Mention the ldexp-ieee module.
* doc/posix-functions/ldexpf.texi: Mention the ldexpf-ieee module.
* doc/posix-functions/ldexpl.texi: Mention the ldexpl-ieee module.
* doc/posix-functions/log10l.texi: Mention the log10l-ieee module.
* doc/posix-functions/log2l.texi: Mention the log2l-ieee module.
* doc/posix-functions/logb.texi: Mention the logb-ieee module.
* doc/posix-functions/logbf.texi: Mention the logbf-ieee module.
* doc/posix-functions/logbl.texi: Mention the logbl-ieee module.
* doc/posix-functions/logl.texi: Mention the logl-ieee module.
* doc/posix-functions/rint.texi: Mention the rint-ieee module.
* doc/posix-functions/rintf.texi: Mention the rintf-ieee module.
* doc/posix-functions/rintl.texi: Mention the rintl-ieee module.
* doc/posix-functions/sqrt.texi: Mention the sqrt-ieee module.
* doc/posix-functions/sqrtf.texi: Mention the sqrtf-ieee module.
* doc/posix-functions/sqrtl.texi: Mention the sqrtl-ieee module.

diff --git a/doc/posix-functions/cbrt.texi b/doc/posix-functions/cbrt.texi
index a17d6ceb4e..c7ab45713f 100644
--- a/doc/posix-functions/cbrt.texi
+++ b/doc/posix-functions/cbrt.texi
@@ -4,8 +4,9 @@
 
 POSIX specification:@* 
@url{https://pubs.opengroup.org/onlinepubs/9799919799/functions/cbrt.html}
 
-Gnulib module: cbrt
+Gnulib module: cbrt or cbrt-ieee
 @mindex cbrt
+@mindex cbrt-ieee
 
 Portability problems fixed by Gnulib:
 @itemize
diff --git a/doc/posix-functions/cbrtf.texi b/doc/posix-functions/cbrtf.texi
index 7f2f7f2fb3..0802e4bfff 100644
--- a/doc/posix-functions/cbrtf.texi
+++ b/doc/posix-functions/cbrtf.texi
@@ -4,8 +4,9 @@
 
 POSIX specification:@* 
@url{https://pubs.opengroup.org/onlinepubs/9799919799/functions/cbrtf.html}
 
-Gnulib module: cbrtf
+Gnulib module: cbrtf or cbrtf-ieee
 @mindex cbrtf
+@mindex cbrtf-ieee
 
 Portability problems fixed by Gnulib:
 @itemize
diff --git a/doc/posix-functions/exp.texi b/doc/posix-functions/exp.texi
index 6ec58d232f..7e57e501db 100644
--- a/doc/posix-functions/exp.texi
+++ b/doc/posix-functions/exp.texi
@@ -4,8 +4,9 @@
 
 POSIX specification:@* 
@url{https://pubs.opengroup.org/onlinepubs/9799919799/functions/exp.html}
 
-Gnulib module: exp
+Gnulib module: exp or exp-ieee
 @mindex exp
+@mindex exp-ieee
 
 Portability problems fixed by Gnulib:
 @itemize
diff --git a/doc/posix-functions/exp2.texi b/doc/posix-functions/exp2.texi
index 9ed7eb5519..dd5800d1f6 100644
--- a/doc/posix-functions/exp2.texi
+++ b/doc/posix-functions/exp2.texi
@@ -4,8 +4,9 @@
 
 POSIX specification:@* 
@url{https://pubs.opengroup.org/onlinepubs/9799919799/functions/exp2.html}
 
-Gnulib module: exp2
+Gnulib module: exp2 or exp2-ieee
 @mindex exp2
+@mindex exp2-ieee
 
 Portability problems fixed by Gnulib:
 @itemize
diff --git a/doc/posix-functions/exp2f.texi b/doc/posix-functions/exp2f.texi
index ab3ddecc4f..74eedeece8 100644
--- a/doc/posix-functions/exp2f.texi
+++ b/doc/posix-functions/exp2f.texi
@@ -4,8 +4,9 @@
 
 POSIX specification:@* 
@url{https://pubs.opengroup.org/onlinepubs/9799919799/functions/exp2f.html}
 
-Gnulib module: exp2f
+Gnulib module: exp2f or exp2f-ieee
 @mindex exp2f
+@mindex exp2f-ieee
 
 Portability problems fixed by Gnulib:
 @itemize
diff --git a/doc/posix-functions/expf.texi b/doc/posix-functions/expf.texi
index 252310ef80..422527b04e 100644
--- a/doc/posix-functions/expf.texi
+++ b/doc/posix-functions/expf.texi
@@ -4,8 +4,9 @@
 
 POSIX specification:@* 
@url{https://pubs.opengroup.org/onlinepubs/9799919799/functions/expf.html}
 
-Gnulib module: expf
+Gnulib module: expf or

_gl_unregister_fd not declared in certain occasions

[Daiki Ueno]

Hello,

When trying to update Gnulib submodule in GnuTLS, I came across this error:

  close.c: In function 'rpl_close':
  close.c:71:5: error: implicit declaration of function '_gl_unregister_fd' 
[-Wimplicit-function-declaration]
 71 | _gl_unregister_fd (fd);
| ^
  make[4]: *** [Makefile:3602: libgnu_la-close.lo] Error 1

Looks like REPLACE_FCHDIR is defined as 1, while fchdir implementation
is not provided by Gnulib (@GNULIB_FCHDIR@ expands to 0, and fchdir.c is
not added to the library sources in the genenerated Makefile).

I haven't managed to minimize the reproducer, but you can easily
reproduce the issue with podman or docker:

  podman run -ti registry.gitlab.com/gnutls/build-images:buildenv-mingw-fedora40
  git clone https://gitlab.com/gnutls/gnutls.git
  (cd gnutls && git submodule deinit gnulib && git rm -rf gnulib)
  git clone https://git.sv.gnu.org/git/gnulib.git
  cd gnutls
  ./bootstrap --skip-po --gnulib-srcdir=$PWD/../gnulib
  ./configure --disable-gcc-warnings --host=x86_64-w64-mingw32 
--target=x86_64-w64-mingw32 --with-included-unistring --disable-full-test-suite 
--disable-doc
  make

After bisecting, the first commit that introduced the issue seems to be:

  commit f59ff6beeb3e5f437a4c847b9e1a785b30363e5b
  Author: Bruno Haible 
  Date:   Mon Aug 12 16:15:50 2024 +0200

  fdutimensat, utimensat tests: Fix test failures on Cygwin.

Reverting this change fixes the issue locally.

Regards,
-- 
Daiki Ueno

Document the *zprintf functions

[Bruno Haible via Gnulib discussion list]

This patch completes the *zprintf feature, by adding documentation.


2024-12-25  Bruno Haible  

Document the *zprintf functions.
* doc/zprintf.texi: New file.
* doc/gnulib.texi (Particular Modules): Include it.

diff --git a/doc/gnulib.texi b/doc/gnulib.texi
index b7a6110b55..7c27f65ab7 100644
--- a/doc/gnulib.texi
+++ b/doc/gnulib.texi
@@ -8060,6 +8060,7 @@
 * Closed standard fds::
 * Handling strings with NUL characters::
 * Container data types::
+* Modernized printf::
 * Stack traces::
 * Recognizing Option Arguments::
 * Quoting::
@@ -8102,6 +8103,8 @@
 
 @include containers.texi
 
+@include zprintf.texi
+
 @include stack-trace.texi
 
 @include argmatch.texi
=== doc/zprintf.texi ===
@node Modernized printf
@section Modernized printf

@c Copyright (C) 2024 Free Software Foundation, Inc.

@c Permission is granted to copy, distribute and/or modify this document
@c under the terms of the GNU Free Documentation License, Version 1.3 or
@c any later version published by the Free Software Foundation; with no
@c Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.  A
@c copy of the license is at .

@c Written by Bruno Haible.

The @code{*zprintf} family of functions is
a modernized form of the @code{*printf} family of functions.

@subheading The problem

The @code{*printf} functions have a return type @samp{int}
and therefore can only produce results that are up to (2 GiB - 1 byte) long.

The problem with this is not so much that it is an arbitrary limitation
(that persists even in processes that have, say, 50 GiB of RAM available).
The bigger problem is that in reliable programs,
it requires handling of an error code @code{EOVERFLOW}
that indicates a result whose size would be 2 GiB or larger.

@c A symptom of this missing EOVERFLOW handling can be
@c warnings from static analyzers, see e.g.
@c https://lists.gnu.org/archive/html/bug-gnulib/2023-06/msg00014.html

How does a reliable program do error handling of @code{*printf} function calls?
For output to strings and file descriptors
(such as @code{sprintf} and @code{dprintf}),
there is no other way than to check each such call.

For output to @code{FILE} streams (such as @code{fprintf}),
beginners are tempted to ignore the return value of each call
and instead check @code{ferror (stream)} at the end.
The problem with this approach is that
at the moment the error is detected,
incorrect output has already been sent onto the stream.
So, in this case as well, the reliable approach is to check each such call.

The @emph{simple format strings} that most programs use in 99% of the places,
namely with no wide string or wide character arguments,
nor with widths passed as @code{int} argument,
can only fail with two possible error codes:
@itemize
@item
@code{ENOMEM}, when
the result would be too large to allocate in the process' memory.
@item
@code{EOVERFLOW}, when
the result is 2 GiB or larger but still allocatable.
@end itemize

Many GNU programs use ``checking'' wrappers (functions @code{xvasprintf}, etc.)
that check for @code{ENOMEM} and call @code{xalloc_die},
thus aborting the program in that case.
The problem is that @code{EOVERFLOW} is not handled, even with such wrappers.

Should @code{EOVERFLOW} be handled like @code{ENOMEM}, by aborting the program?
No, as mentioned above, that would be an arbitrary limitation, which the
GNU Coding Standards urge us to avoid
(@pxref{Semantics,,, standards, GNU Coding Standards}).

@subheading The solution

The @code{*zprintf} functions are like the @code{*printf} functions,
except that the return type is
@itemize
@item
@code{ptrdiff_t} instead of @code{int},
for output to strings,
@item
@code{off64_t} (which is always equivalent to @code{int64_t})
instead of @code{int},
for output to file streams and file descriptors.
@end itemize
@noindent
Thus, for these functions, @code{EOVERFLOW} cannot occur
(except for format strings which take widths as argument,
which we have excluded above),
and the ``checking'' wrappers (functions @code{xvasprintf}, etc.)
are thus sufficient for ensuring an error-free result.

Note:
In 64-bit processes, @code{ptrdiff_t} is 64 bits wide,
i.e. equivalent to @code{int64_t}.
In 32-bit processes, @code{ptrdiff_t} is only 32 bits wide,
but since in these environments,
memory regions of 2 GiB or larger cannot be allocated anyway
(@code{malloc} would fail with @code{ENOMEM}),
this type is sufficient.

The following Gnulib functions and modules exist:

@mindex szprintf
@mindex szprintf-posix
@mindex szprintf-gnu
@mindex vszprintf
@mindex vszprintf-posix
@mindex vszprintf-gnu
@mindex snzprintf
@mindex snzprintf-posix
@mindex snzprintf-gnu
@mindex vsnzprintf
@mindex vsnzprintf-posix
@mindex vsnzprintf-gnu
@mindex vaszprintf
@mindex vaszprintf-posix
@mindex vaszprintf-gnu
@mindex c-snzprintf
@mindex c-snzprintf-gnu
@mindex c-vsnzprintf
@mindex c-vsnzprintf-gnu
@mindex c-v

Re: [PATCH 2/2] stdlib: fix MB_CUR_MAX on older Android

[Bruno Haible via Gnulib discussion list]

Paul Eggert wrote:
> +[AC_LINK_IFELSE(
> + [AC_LANG_PROGRAM([[#include 
> +  ]],
> +  [[return !!MB_CUR_MAX;]])],
> + [dnl Initial guess, used when cross-compiling or when no suitable locale

With only 1 column of indentation, I have a hard time understanding the
structure of this code. Need to indent it better, for readability:


2024-12-25  Bruno Haible  

stdlib: Improve change from 2024-12-23.
* m4/stdlib_h.m4 (gl_STDLIB_H): Improve indentation.

diff --git a/m4/stdlib_h.m4 b/m4/stdlib_h.m4
index f1192e3d25..ba56a9480b 100644
--- a/m4/stdlib_h.m4
+++ b/m4/stdlib_h.m4
@@ -1,5 +1,5 @@
 # stdlib_h.m4
-# serial 83
+# serial 84
 dnl Copyright (C) 2007-2024 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -42,19 +42,20 @@ AC_DEFUN_ONCE([gl_STDLIB_H]
   AC_CACHE_CHECK([whether MB_CUR_MAX is correct],
 [gl_cv_macro_MB_CUR_MAX_good],
 [AC_LINK_IFELSE(
- [AC_LANG_PROGRAM([[#include 
-  ]],
-  [[return !!MB_CUR_MAX;]])],
- [dnl Initial guess, used when cross-compiling or when no suitable locale
-  dnl is present.
-  # Guess no on Solaris and Haiku, yes otherwise.
-  AS_CASE([$host_os],
-[solaris* | haiku*],
-  [gl_cv_macro_MB_CUR_MAX_good="guessing no"],
-  [gl_cv_macro_MB_CUR_MAX_good="guessing yes"])
-  if test "$LOCALE_EN_UTF8" != none; then
-AC_RUN_IFELSE(
-  [AC_LANG_SOURCE([[
+   [AC_LANG_PROGRAM([[#include 
+]],
+[[return !!MB_CUR_MAX;]])
+   ],
+   [dnl Initial guess, used when cross-compiling or when no suitable locale
+dnl is present.
+# Guess no on Solaris and Haiku, yes otherwise.
+AS_CASE([$host_os],
+  [solaris* | haiku*],
+[gl_cv_macro_MB_CUR_MAX_good="guessing no"],
+[gl_cv_macro_MB_CUR_MAX_good="guessing yes"])
+if test "$LOCALE_EN_UTF8" != none; then
+  AC_RUN_IFELSE(
+[AC_LANG_SOURCE([[
 #include 
 #include 
 int main ()
@@ -67,12 +68,12 @@ AC_DEFUN_ONCE([gl_STDLIB_H]
 }
   return result;
 }]])],
-  [gl_cv_macro_MB_CUR_MAX_good=yes],
-  [gl_cv_macro_MB_CUR_MAX_good=no],
-  [:])
-  fi
- ],
- [gl_cv_macro_MB_CUR_MAX_good="link failed - so no"])
+[gl_cv_macro_MB_CUR_MAX_good=yes],
+[gl_cv_macro_MB_CUR_MAX_good=no],
+[:])
+fi
+   ],
+   [gl_cv_macro_MB_CUR_MAX_good="link failed - so no"])
 ])
   AS_CASE([$gl_cv_macro_MB_CUR_MAX_good],
 [*yes],

Re: reviewing patches

[Bruno Haible via Gnulib discussion list]

Paul Eggert wrote:
> Thanks, my earlier patch had that limited indentation only to make its 
> diff easier to review (since it kept the existing physical indentation 
> while increasing logical indentation).

While this is a consideration in projects which review patches before
they are committed (e.g. glibc), here in most cases we review patches
that are already committed, and with 'gitk' the reviewer not only has
the option "Ignore space change", but also the option to increase the
number of context lines to 10 or 30. I couldn't do some code reviews
without 'gitk'.

Bruno

Re: supporting in the UTF-8 environment on native Windows

[Lasse Collin]

On 2024-12-24 Bruno Haible wrote:
> Lasse Collin wrote:
> > (1)
> > In 9f7ff4f423cd ("localename-unsafe: Support the UTF-8 environment
> > on native Windows."), the N(name) macro is used with strings that
> > include @modifier. For example, N("az_AZ@cyrillic") can expand to
> > "az...@cyrillic.utf-8". Similarly in 00211fc69c92 ("setlocale:
> > Support the UTF-8 environment on native Windows."), ".65001" is
> > appended after the @modifier. However, the typical order would be
> > az_AZ.UTF-8@cyrillic.
> 
> Good point. Fixed through the patch below.

Thanks. Isn't there a similar issue in setlocale.c after the commit
00211fc69c92?

  /* llCC_buf now contains
   language[_territory][@modifier]
   */
  if (strcmp (llCC_buf, locale) != 0)
{
  if (is_utf8)
{
  char buf[64+6];
  strcpy (buf, llCC_buf);
  strcat (buf, ".65001");
  result = setlocale (category, buf);
}
  else
result = setlocale (category, llCC_buf);

> > I suppose you had a reason to use .65001 instead of .UTF-8 or .utf8.
> > I expect identical behavior from those.  
> 
> Yes: There was some period (ca. 5 years ago) when Windows supported
> the .65001 suffix but not the .utf8 suffix. The ability to use .utf8
> to denote code page 65001 was added a bit later.
[...]
> Yeah, the docs don't tell you everything (as usual with Microsoft).

Makes sense. Thanks for the explanation.

> > (2)
> > In 2f4391fde862 ("setlocale tests: Test in the UTF-8 environment on
> > native Windows."), the condition
> > 
> > (strlen (name) > 6 && strcmp (name + strlen (name) - 6,
> > ".UTF-8") == 0)
> > 
> > matches the two long strings below it too, making those two extra
> > strcmp calls redundant.  
> 
> Correct. Still, it's useful to have a writedown of what the output in
> the legacy mode is. (Unit test code is not optimized for performance.)

I agree it's a fine way to document things. It could be useful to have
a comment saying that those conditions are there for documentation
purposes.

> > (3)
> > When a manifest is added via a resource file, a possible default
> > manifest from the toolchain is replaced; they aren't merged. For
> > example, on MSYS2, the mingw-w64-ucrt-x86_64-gcc package depends on
> > mingw-w64-ucrt-x86_64-windows-default-manifest. The manifest comes
> > from Cygwin:
> > 
> > 
> > https://sourceware.org/git/?p=cygwin-apps/windows-default-manifest.git;a=blob;f=default-manifest.rc
> > 
> > Omitting the  section makes the application run with
> > Vista as the Operating System Context. Omitting the 
> > section makes Windows treat the application as not UAC compliant,
> > that is, a pre-Vista app that needs compatibility tricks.
> > 
> > Probably these don't matter with the current tests. I suggest
> > changing it still because it's still an odd combination to have
> > UTF-8 without marking the app compatible with recent Windows
> > versions.  
> 
> I picked the smallest XML file that has the desired effect.
> 
> Also, I don't like enumerating Windows versions in this way because
> it's not future-proof: Since Windows 11, 12, 13, etc. are not listed,
> it would only be matter of time until the test breaks in a new Windows
> version.

It's only a test program which doesn't affect the binaries being
installed. As long as it works for testing I guess it's fine enough.

One clarification though: If one omits , Win10 behaves
as if you had put only Vista compatibility in the manifest: Task
Manager shows Vista as the Operating System Context for the program.
That is, one is sort of requesting "emulation" of Vista in that case.

There is no separate entry for Windows 11 because Windows 10 and 11 use
the same entry. What will happen with Win12 is unknown, of course.

> > (4)
> > The output from windres goes to a file with the .res suffix but the
> > format is overridden with --output-format=coff. This looks weird
> > because windres defaults to --output-format=res for files that use
> > the .res suffix. For coff, the .o suffix would be logical, and
> > --output-format option wouldn't be needed.  
> 
> Maybe it looks weird, but IIRC it's the best way that I found that
> does not run into 32-bit / 64-bit problems. For example, if 'windres'
> is 64-bit but I'm compiling with a 32-bit targetting gcc. (Some
> toolchain installations have a -windres program, but some
> other toolchain installations have only one windres program for all
> targets.)

OK. It was only the .res suffix that looked weird because windres
already recognizes .res for a different file format than COFF.

-- 
Lasse Collin

Re: supporting in the UTF-8 environment on native Windows

[Bruno Haible via Gnulib discussion list]

Lasse Collin wrote:
> Thanks. Isn't there a similar issue in setlocale.c after the commit
> 00211fc69c92?
> 
>   /* llCC_buf now contains
>language[_territory][@modifier]
>*/
>   if (strcmp (llCC_buf, locale) != 0)
> {
>   if (is_utf8)
> {
>   char buf[64+6];
>   strcpy (buf, llCC_buf);
>   strcat (buf, ".65001");
>   result = setlocale (category, buf);
> }
>   else
> result = setlocale (category, llCC_buf);

Possibly. But I don't know whether Windows supports locale names with a
modifier at all; therefore it would require testing. And since I guess
that there are only few users of such a locale, this testing does not
have high priority.

> It's only a test program which doesn't affect the binaries being
> installed. As long as it works for testing I guess it's fine enough.

Yes, that's why I purposely kept things as simple as needed. For an
application with actual users, the XML file can be as complicated as
Microsoft wants it.

Bruno

xprintf, xprintf-posix, xprintf-gnu: Use *zprintf

[Bruno Haible via Gnulib discussion list]

The *zprintf patches from end of June 2024 are not yet complete. The
only remaining modules with *printf functions which have an 'int' return
type are
  xprintf, xprintf-posix, xprintf-gnu.

It appears from looking at the code that invokes the functions x[v][f]printf
(cf. maint-tools/code-search.txt) that all users ignore the return value.
Therefore we don't need new modules
  xzprintf, xzprintf-posix, xzprintf-gnu
but can instead just reuse these modules and merely change the return type.

Done through this patch:


2024-12-25  Bruno Haible  

xprintf, xprintf-posix, xprintf-gnu: Use *zprintf.
* lib/xprintf.h (xprintf, xvprintf, xfprintf, xvfprintf): Change return
type to off64_t. Move documentation from xprintf.c to here. Mention
EOVERFLOW as another possible error unrelated to file I/O.
* lib/xprintf.c (xprintf): Change return type to off64_t.
(xvprintf): Likewise. Use vzprintf.
(xfprintf): Change return type to off64_t.
(xvfprintf): Likewise. Use vfzprintf.
* modules/xprintf (Description): Mention also fprintf. Mention EOVERFLOW
as another possible error unrelated to file I/O.
(Depends-on): Add vzprintf, vfzprintf.
* modules/xprintf-posix (Description): Mention also fprintf. Mention
EOVERFLOW as another possible error unrelated to file I/O.
(Depends-on): Add vzprintf-posix, vfzprintf-posix. Remove vprintf-posix,
vfprintf-posix.
* modules/xprintf-gnu (Description): Mention also fprintf. Mention
EOVERFLOW as another possible error unrelated to file I/O.
(Depends-on): Add vzprintf-gnu, vfzprintf-gnu. Remove vprintf-gnu,
vfprintf-gnu.
* tests/test-xprintf-posix.c (RETTYPE): Change to off64_t.
* tests/test-xfprintf-posix.c (RETTYPE): Likewise.
* NEWS: Document the change.

diff --git a/NEWS b/NEWS
index 9e08bd1048..e64d1583f8 100644
--- a/NEWS
+++ b/NEWS
@@ -74,6 +74,9 @@ User visible incompatible changes
 
 DateModules Changes
 
+2024-12-25  xprintf The functions x[v][f]printf now return an 'off64_t'
+instead of an 'int'.
+
 2024-11-05  eealloc This module is deprecated.  Use malloc-gnu or
 realloc-posix instead.
 
diff --git a/lib/xprintf.c b/lib/xprintf.c
index 732bbea407..5d01874b63 100644
--- a/lib/xprintf.c
+++ b/lib/xprintf.c
@@ -14,6 +14,8 @@
You should have received a copy of the GNU General Public License
along with this program.  If not, see .  */
 
+/* written by Jim Meyering */
+
 #include 
 
 #include "xprintf.h"
@@ -26,15 +28,11 @@
 
 #define _(msgid) dgettext ("gnulib", msgid)
 
-/* written by Jim Meyering */
-
-/* Just like printf, but call error if it fails without setting the
-   stream's error indicator.  */
-int
+off64_t
 xprintf (char const *restrict format, ...)
 {
   va_list args;
-  int retval;
+  off64_t retval;
   va_start (args, format);
   retval = xvprintf (format, args);
   va_end (args);
@@ -42,25 +40,21 @@ xprintf (char const *restrict format, ...)
   return retval;
 }
 
-/* Just like vprintf, but call error if it fails without setting the
-   stream's error indicator.  */
-int
+off64_t
 xvprintf (char const *restrict format, va_list args)
 {
-  int retval = vprintf (format, args);
+  off64_t retval = vzprintf (format, args);
   if (retval < 0 && ! ferror (stdout))
 error (exit_failure, errno, _("cannot perform formatted output"));
 
   return retval;
 }
 
-/* Just like fprintf, but call error if it fails without setting the
-   stream's error indicator.  */
-int
+off64_t
 xfprintf (FILE *restrict stream, char const *restrict format, ...)
 {
   va_list args;
-  int retval;
+  off64_t retval;
   va_start (args, format);
   retval = xvfprintf (stream, format, args);
   va_end (args);
@@ -68,12 +62,10 @@ xfprintf (FILE *restrict stream, char const *restrict 
format, ...)
   return retval;
 }
 
-/* Just like vfprintf, but call error if it fails without setting the
-   stream's error indicator.  */
-int
+off64_t
 xvfprintf (FILE *restrict stream, char const *restrict format, va_list args)
 {
-  int retval = vfprintf (stream, format, args);
+  off64_t retval = vfzprintf (stream, format, args);
   if (retval < 0 && ! ferror (stream))
 error (exit_failure, errno, _("cannot perform formatted output"));
 
diff --git a/lib/xprintf.h b/lib/xprintf.h
index 202dbd2022..c30b5080a0 100644
--- a/lib/xprintf.h
+++ b/lib/xprintf.h
@@ -1,4 +1,4 @@
-/* printf wrappers that fail immediately for non-file-related errors
+/* printf and fprintf wrappers that fail immediately for non-file-related 
errors
Copyright (C) 2007-2024 Free Software Foundation, Inc.
 
This program is free software: you can redistribute it and/or modify
@@ -30,7 +30,9 @@ extern "C" {
 #endif
 
 
-extern int xprintf (char const *restrict format, ...)
+/* Like zprintf, but call error if it fails without setting stdo

Re: [PATCH 2/2] stdlib: fix MB_CUR_MAX on older Android

[Paul Eggert]

On 2024-12-25 06:17, Bruno Haible wrote:

Paul Eggert wrote:

+[AC_LINK_IFELSE(
+ [AC_LANG_PROGRAM([[#include 
+  ]],
+  [[return !!MB_CUR_MAX;]])],
+ [dnl Initial guess, used when cross-compiling or when no suitable locale


With only 1 column of indentation, I have a hard time understanding the
structure of this code. Need to indent it better, for readability:


Thanks, my earlier patch had that limited indentation only to make its 
diff easier to review (since it kept the existing physical indentation 
while increasing logical indentation).