vasnwprintf: Fix test failures on musl libc

[Bruno Haible]

On musl libc, test-vasnwprintf-posix fails. This is due to two musl libc bugs:
  https://www.openwall.com/lists/musl/2023/03/19/1
  https://www.openwall.com/lists/musl/2023/03/20/1

As a workaround, on this platform, vasnwprintf needs to
  - avoid %n,
  - do the padding itself, instead of leaving it to the swprintf primitive.


2023-03-19  Bruno Haible  

vasnwprintf: Fix test failures on musl libc.
* m4/vasnprintf.m4 (gl_PREREQ_VASNWPRINTF): Invoke gl_MUSL_LIBC.
* lib/vasnprintf.c (VASNPRINTF): On musl libc, when WIDE_CHAR_VERSION,
- force pad_ourselves to be 1,
- don't use %n.
Fix zero-padding when the result starts with a prefix "0x" or "0b".
* modules/vasnwprintf (Files): Add musl.m4.
* doc/posix-functions/swprintf.texi: Mention two musl libc bugs.

diff --git a/doc/posix-functions/swprintf.texi 
b/doc/posix-functions/swprintf.texi
index 906ee521aa..a87bc06c86 100644
--- a/doc/posix-functions/swprintf.texi
+++ b/doc/posix-functions/swprintf.texi
@@ -26,11 +26,21 @@
 glibc when used with @code{_FORTIFY_SOURCE >= 2} (set by default on Ubuntu),
 macOS 11.1, MSVC 14.
 @item
+This function sometimes returns a wrong value through the @samp{n} directive
+on some platforms:
+@c https://www.openwall.com/lists/musl/2023/03/19/1
+musl libc 1.2.3.
+@item
 On Windows and 32-bit AIX platforms, @code{wchar_t} is a 16-bit type and 
therefore cannot
 accommodate all Unicode characters.
 @item
 On Windows, this function does not take a buffer size as second argument.
 @item
+This function ignores the minimum field width in the @samp{lc} directive
+on some platforms:
+@c https://www.openwall.com/lists/musl/2023/03/20/1
+musl libc 1.2.3.
+@item
 This function does not support the @samp{b} directive, required by ISO C23,
 on some platforms:
 glibc 2.34, musl libc, macOS 12.5, FreeBSD 13.1, NetBSD 9.0, OpenBSD 7.2,
diff --git a/lib/vasnprintf.c b/lib/vasnprintf.c
index c2f10cb0c4..50ff2e64dd 100644
--- a/lib/vasnprintf.c
+++ b/lib/vasnprintf.c
@@ -4932,7 +4932,7 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp,
   {
 arg_type type = a.arg[dp->arg_index].type;
 int flags = dp->flags;
-#if !DCHAR_IS_TCHAR || ENABLE_UNISTDIO || NEED_PRINTF_FLAG_LEFTADJUST || 
NEED_PRINTF_FLAG_ZERO || NEED_PRINTF_UNBOUNDED_PRECISION
+#if (WIDE_CHAR_VERSION && MUSL_LIBC) || !DCHAR_IS_TCHAR || ENABLE_UNISTDIO || 
NEED_PRINTF_FLAG_LEFTADJUST || NEED_PRINTF_FLAG_ZERO || 
NEED_PRINTF_UNBOUNDED_PRECISION
 int has_width;
 #endif
 #if !USE_SNPRINTF || WIDE_CHAR_VERSION || !HAVE_SNPRINTF_RETVAL_C99 || 
USE_MSVC__SNPRINTF || !DCHAR_IS_TCHAR || ENABLE_UNISTDIO || 
NEED_PRINTF_FLAG_LEFTADJUST || NEED_PRINTF_FLAG_ZERO || 
NEED_PRINTF_UNBOUNDED_PRECISION
@@ -4947,7 +4947,7 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp,
 #else
 #   define prec_ourselves 0
 #endif
-#if NEED_PRINTF_FLAG_LEFTADJUST
+#if (WIDE_CHAR_VERSION && MUSL_LIBC) || NEED_PRINTF_FLAG_LEFTADJUST
 #   define pad_ourselves 1
 #elif !DCHAR_IS_TCHAR || ENABLE_UNISTDIO || NEED_PRINTF_FLAG_ZERO || 
NEED_PRINTF_UNBOUNDED_PRECISION
 int pad_ourselves;
@@ -4964,7 +4964,7 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp,
 TCHAR_T *tmp;
 #endif
 
-#if !DCHAR_IS_TCHAR || ENABLE_UNISTDIO || NEED_PRINTF_FLAG_LEFTADJUST || 
NEED_PRINTF_FLAG_ZERO || NEED_PRINTF_UNBOUNDED_PRECISION
+#if (WIDE_CHAR_VERSION && MUSL_LIBC) || !DCHAR_IS_TCHAR || ENABLE_UNISTDIO || 
NEED_PRINTF_FLAG_LEFTADJUST || NEED_PRINTF_FLAG_ZERO || 
NEED_PRINTF_UNBOUNDED_PRECISION
 has_width = 0;
 #endif
 #if !USE_SNPRINTF || WIDE_CHAR_VERSION || !HAVE_SNPRINTF_RETVAL_C99 || 
USE_MSVC__SNPRINTF || !DCHAR_IS_TCHAR || ENABLE_UNISTDIO || 
NEED_PRINTF_FLAG_LEFTADJUST || NEED_PRINTF_FLAG_ZERO || 
NEED_PRINTF_UNBOUNDED_PRECISION
@@ -4995,7 +4995,7 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp,
   width = xsum (xtimes (width, 10), *digitp++ - '0');
 while (digitp != dp->width_end);
   }
-#if !DCHAR_IS_TCHAR || ENABLE_UNISTDIO || NEED_PRINTF_FLAG_LEFTADJUST || 
NEED_PRINTF_FLAG_ZERO || NEED_PRINTF_UNBOUNDED_PRECISION
+#if (WIDE_CHAR_VERSION && MUSL_LIBC) || !DCHAR_IS_TCHAR || ENABLE_UNISTDIO || 
NEED_PRINTF_FLAG_LEFTADJUST || NEED_PRINTF_FLAG_ZERO || 
NEED_PRINTF_UNBOUNDED_PRECISION
 has_width = 1;
 #endif
   }
@@ -5050,7 +5050,7 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp,
 #endif
 
 /* Decide whether to perform the padding ourselves.  */
-#if !NEED_PRINTF_FLAG_LEFTADJUST && (!DCHAR_IS_TCHAR || ENABLE_UNISTDIO || 
NEED_PRINTF_FLAG_ZERO || NEED_PRINTF_UNBOUNDED_PRECISION)
+#if !((WIDE_CHAR_VERSION && MUSL_LIBC) || NEED_PRINTF_FLAG_LEFTADJUST) && 
(!DCHAR_IS_TCHAR || ENABLE_UNISTDIO || NEED_PRINTF_FLAG_ZERO || 
NEED_PRINTF_UNBOUNDED_PRECISION)
 switch (dp->conversion)
   {
 # if 

vasnwprintf: Fix module dependencies

[Bruno Haible]

The vasnwprintf implementation and tests depend on a few wide-character string
functions from . This patch adds the dependencies.

It also depends on 'swprintf'; to be added later.


2023-03-19  Bruno Haible  

vasnwprintf: Fix module dependencies.
* modules/vasnwprintf (Depends-on): Add wmemcpy, wmemset.
* modules/vasnwprintf-tests (Depends-on): Add wmemcmp.
* modules/vasnwprintf-posix-tests (Depends-on): Likewise.

diff --git a/modules/vasnwprintf b/modules/vasnwprintf
index 544d7144a4..6c7d63a5f6 100644
--- a/modules/vasnwprintf
+++ b/modules/vasnwprintf
@@ -34,6 +34,8 @@ errno
 memchr
 assert-h
 wchar
+wmemcpy
+wmemset
 
 configure.ac:
 AC_REQUIRE([AC_C_RESTRICT])
diff --git a/modules/vasnwprintf-posix-tests b/modules/vasnwprintf-posix-tests
index 4f2891a4ff..d9729e9dcb 100644
--- a/modules/vasnwprintf-posix-tests
+++ b/modules/vasnwprintf-posix-tests
@@ -16,6 +16,7 @@ float
 setlocale
 wcscmp
 wcsspn
+wmemcmp
 wmemcpy
 
 configure.ac:
diff --git a/modules/vasnwprintf-tests b/modules/vasnwprintf-tests
index e90236e8d2..37ed08de56 100644
--- a/modules/vasnwprintf-tests
+++ b/modules/vasnwprintf-tests
@@ -4,6 +4,7 @@ tests/macros.h
 
 Depends-on:
 wcscmp
+wmemcmp
 wmemcpy
 
 configure.ac:

Re: bug#62267: grep-3.9 bug: \d matches multibyte digits

[Jim Meyering]

On Sun, Mar 19, 2023 at 4:12 PM Paul Eggert  wrote:
> On 2023-03-19 13:44, Jim Meyering wrote:
> > I've pushed your change along with the attached.
> > I'll probably create another snapshot today.
>
> Thanks. I also installed a minor dfa.c change in Gnulib yesterday to
> pacify Oracle Solaris Studio. No big deal since 'grep' builds OK anyway.
>
> I also ran into a weird issue with test-select on Fedora 37 x86-64. It
> appears to be timing dependent and usually doesn't happen. I can't
> reproduce under strace. This is another Gnulib thing and not relevant to
> grep (other than people might report test failures to bug-grep).
>
> I installed into Gnulib the attached patch which shouldn't hurt but
> which I don't know fixes the bug.

Oh! I must have missed getting the latter by bare minutes.
I've just published another snapshot (which does include the dfa.c change)
but not the select one. We'll get it for the release of 3.10

Re: bug#62267: grep-3.9 bug: \d matches multibyte digits

[Paul Eggert]

On 2023-03-19 13:44, Jim Meyering wrote:

I've pushed your change along with the attached.
I'll probably create another snapshot today.


Thanks. I also installed a minor dfa.c change in Gnulib yesterday to 
pacify Oracle Solaris Studio. No big deal since 'grep' builds OK anyway.


I also ran into a weird issue with test-select on Fedora 37 x86-64. It 
appears to be timing dependent and usually doesn't happen. I can't 
reproduce under strace. This is another Gnulib thing and not relevant to 
grep (other than people might report test failures to bug-grep).


I installed into Gnulib the attached patch which shouldn't hurt but 
which I don't know fixes the bug.diff --git a/ChangeLog b/ChangeLog
index dfce1a8df7..f42e2ede30 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2023-03-19  Paul Eggert  
+
+	test-pselect, test-select: use different ports
+	I have observed rare and hard-to-reproduce problems with the GNU
+	grep release candidate with ‘make -j5 check’ on Fedora 37 x86-64.
+	One possibility is that test-pselect and test-select interfere
+	with each other somehow when run simultaneously, as they use the
+	same port.  Work around this possibility by using different ports
+	from each other, and from test-poll (which also uses 12345).
+	Of course it’d be better if all these tests used system-assigned
+	ports, but I assume that’d take more work.
+	* tests/test-pselect.c, tests/test-select.c (TEST_PORT): New macro.
+	* tests/test-select.h (TEST_PORT): Remove.
+
 2023-03-19  Bruno Haible  
 
 	Update MODULES.html.sh.
diff --git a/tests/test-pselect.c b/tests/test-pselect.c
index 41468684c5..a383f1d1b2 100644
--- a/tests/test-pselect.c
+++ b/tests/test-pselect.c
@@ -24,6 +24,7 @@ SIGNATURE_CHECK (pselect, int,
  (int, fd_set *restrict, fd_set *restrict, fd_set *restrict,
   struct timespec const *restrict, const sigset_t *restrict));
 
+#define TEST_PORT 12347
 #include "test-select.h"
 
 static int
diff --git a/tests/test-select.c b/tests/test-select.c
index d04be58418..b460060351 100644
--- a/tests/test-select.c
+++ b/tests/test-select.c
@@ -25,6 +25,7 @@
 SIGNATURE_CHECK (select, int, (int, fd_set *, fd_set *, fd_set *,
struct timeval *));
 
+#define TEST_PORT 12346
 #include "test-select.h"
 
 int
diff --git a/tests/test-select.h b/tests/test-select.h
index afa996f40c..ceeb485471 100644
--- a/tests/test-select.h
+++ b/tests/test-select.h
@@ -37,8 +37,6 @@
 # include 
 #endif
 
-#define TEST_PORT   12345
-
 
 typedef int (*select_fn) (int, fd_set *, fd_set *, fd_set *, struct timeval *);
 

Re: coreutils-9.1.198-e68b1.tar.xz on Linux/sparc64

[Sam James]

Bruno Haible  writes:

> Hi Sam,

Hi Bruno,
>
>> The test-pthread-cond test fails for me.
>> 
>> gnulib-tests/test-pthread-cond.log doesn't have much detail:
>> ```
>> Starting test_pthread_cond_wait ... OK
>> Starting test_pthread_cond_timedwait ...FAIL test-pthread-cond (exit
>> status: 134)
>> ```
>
> Is it reproducible?

I managed to hit it once again just now with make check -j256, but
when I ran manually with 'make check' in gnulib-tests, and then ran
the individual test too, it passed repeatedly, so...

>
> I'm asking because on the two Linux/sparc64 machines I have access to,
> this test succeeds.
>
> - Machine 1: Debian EGLIBC 2.13-38+deb7u10, Debian 7.11
>   FAIL: test-fnmatch
>   FAIL: test-getcwd.sh
> - Machine 2: Debian GLIBC 2.24-9
>   All gnulib-tests pass.
>
> This is both in 32-bit mode and in 64-bit mode.
>
> Could it be that your machine was overloaded and thus slow when you ran
> the tests?

... I suspect you're right, and we needn't worry. Thank you!

>
> Bruno



signature.asc
Description: PGP signature

gnu-web-doc-update doesn't work when the manual isn't already online

[Reuben Thomas]

I spent a while trying to work out why I was getting CVS errors from the
script for GNU a2ps, and I realised that the problem was that a2ps's manual
wasn't online yet. This causes confusing error messages when the "manual"
subdirectory isn't online, and cvs can't find a CVS directory and hence
CVSROOT.

I think it would be sufficient to "cvs add" the manual subdirectory before
trying to "cvs add" its contents, adding

( cd pkg && $CVS add manual )

at line 180.

-- 
https://rrt.sc3d.org

Re: [PATCH] Update MODULES.html.sh

[Bruno Haible]

> * MODULES.html.sh: Add some recently-added modules.

Thanks, Paul.

> Assuming MODULES.html.sh is still useful,
> at some point a more-complete update should be done.

While I refer more people to the gnulib.texi documentation than to
MODULES.html, I still think that MODULES.html is useful to get (part of)
the big picture of the modules. The 20 documentation chapters also
attempt to give a big picture; I think both are complementary.

Also, for people who have not yet grokked the concept of a module
description, MODULES.html can be useful.

> ... then added more modules until I ran out of, errr, time.

It's a pity that there is no time zone where time runs slower than in
the conventional time zones :)


2023-03-19  Bruno Haible  

Update MODULES.html.sh.
* MODULES.html.sh: Move stack, wmempcpy, bison to different sections.
Fix a HTML layout problem.

diff --git a/MODULES.html.sh b/MODULES.html.sh
index 6c8bf965c6..714aedd308 100755
--- a/MODULES.html.sh
+++ b/MODULES.html.sh
@@ -1753,7 +1753,6 @@ func_all_modules ()
   func_module immutable
   func_module malloc-h
   func_module ssfmalloc
-  func_module stack
   func_module xsize
   func_module xalloc
   func_module xalloc-die
@@ -1850,7 +1849,6 @@ func_all_modules ()
   func_module trim
   func_module fstrcmp
   func_module xstrndup
-  func_module wmempcpy
   func_end_table
 
   element="Mathematics "
@@ -1923,6 +1921,16 @@ func_all_modules ()
   func_module strsignal
   func_end_table
 
+  element="Wide-character string handling "
+  element=`printf "%s" "$element" | sed -e "$sed_lt" -e "$sed_gt"`
+  func_section_wrap ansic_ext_wchar
+  func_wrap H3
+  func_echo "$element"
+
+  func_begin_table
+  func_module wmempcpy
+  func_end_table
+
   element="Command-line arguments"
   element=`printf "%s" "$element" | sed -e "$sed_lt" -e "$sed_gt"`
   func_section_wrap ansic_ext_argv
@@ -1961,6 +1969,7 @@ func_all_modules ()
   func_module array-oset
   func_module avltree-oset
   func_module rbtree-oset
+  func_module stack
   func_end_table
 
   element="Cryptographic computations (low-level)"
@@ -2440,8 +2449,10 @@ func_all_modules ()
   func_wrap H3
   func_echo "$element"
 
+  func_begin_table
   func_module timespec_get
   func_module timespec_getres
+  func_end_table
 
   element="Support for GNU multiple precision arithmetic"
   func_section_wrap gmp
@@ -3593,7 +3604,6 @@ func_all_modules ()
   func_module argp-version-etc
   func_module argz
   func_module attribute
-  func_module bison
   func_module bitrotate
   func_module byteswap
   func_module dfa
@@ -3639,6 +3649,7 @@ func_all_modules ()
   func_begin_table
   func_module absolute-header
   func_module snippet/arg-nonnull
+  func_module bison
   func_module config-h
   func_module configmake
   func_module dummy

Re: coreutils-9.1.198-e68b1.tar.xz on Linux/sparc64

[Bruno Haible]

Hi Sam,

> The test-pthread-cond test fails for me.
> 
> gnulib-tests/test-pthread-cond.log doesn't have much detail:
> ```
> Starting test_pthread_cond_wait ... OK
> Starting test_pthread_cond_timedwait ...FAIL test-pthread-cond (exit
> status: 134)
> ```

Is it reproducible?

I'm asking because on the two Linux/sparc64 machines I have access to,
this test succeeds.

- Machine 1: Debian EGLIBC 2.13-38+deb7u10, Debian 7.11
  FAIL: test-fnmatch
  FAIL: test-getcwd.sh
- Machine 2: Debian GLIBC 2.24-9
  All gnulib-tests pass.

This is both in 32-bit mode and in 64-bit mode.

Could it be that your machine was overloaded and thus slow when you ran
the tests?

Bruno