Re: [PATCH 2/2] putenv-tests: pacify gcc -Wdiscarded-qualifiers

2024-05-24 Thread Paul Eggert

On 2024-05-24 03:55, Bruno Haible wrote:

It is not spam. It is fully justified, since in
   putenv ((char []) {"TEST_VAR=abc"})
the argument is allocated in automatic storage. See ISO C § 6.5.2.5.(12).


Well, to be fair, the test program removed the string from the 
environment before 'main' returned, so there was no violation of ISO C 
unless the tests fail (and if the tests fail the implementation doesn't 
agree with GNU and all bets are off anyway). I.e., the warning was a 
false positive, although an understandable one.


Anyway, thanks for pacifying GCC.



[PATCH] POSIX.1-2024 has been approved

2024-05-23 Thread Paul Eggert
It hasn’t been published yet, so just update documentation talking
about “draft” POSIX, about particular POSIX versions, etc.
More work will need to be done once it’s published on the web,
to update URLs, better document new and changed interfaces,
and presumably to implement some of the new interfaces.
---
 ChangeLog |  8 +
 MODULES.html.sh   | 36 +--
 .../bind_textdomain_codeset.texi  |  3 +-
 doc/glibc-functions/bindtextdomain.texi   |  3 +-
 doc/glibc-functions/dcgettext.texi|  3 +-
 doc/glibc-functions/dcngettext.texi   |  3 +-
 doc/glibc-functions/dgettext.texi |  3 +-
 doc/glibc-functions/dngettext.texi|  3 +-
 doc/glibc-functions/getentropy.texi   |  3 +-
 doc/glibc-functions/getresgid.texi|  3 +-
 doc/glibc-functions/getresuid.texi|  3 +-
 doc/glibc-functions/gettext.texi  |  3 +-
 doc/glibc-functions/ngettext.texi |  3 +-
 .../posix_spawn_file_actions_addchdir_np.texi |  4 ++-
 ...posix_spawn_file_actions_addfchdir_np.texi |  4 ++-
 .../pthread_cond_clockwait.texi   |  3 ++
 .../pthread_rwlock_clockrdlock.texi   |  3 ++
 .../pthread_rwlock_clockwrlock.texi   |  3 ++
 doc/glibc-functions/ptsname_r.texi|  3 ++
 doc/glibc-functions/sem_clockwait.texi|  3 ++
 doc/glibc-functions/setresgid.texi|  3 +-
 doc/glibc-functions/setresuid.texi|  3 +-
 doc/glibc-functions/textdomain.texi   |  3 +-
 doc/glibc-headers/endian.texi |  3 +-
 doc/pastposix-functions/bcmp.texi |  5 +--
 doc/pastposix-functions/bcopy.texi|  5 +--
 doc/pastposix-functions/bzero.texi|  5 +--
 doc/pastposix-functions/ecvt.texi |  5 +--
 doc/pastposix-functions/fcvt.texi |  5 +--
 doc/pastposix-functions/ftime.texi|  7 ++--
 doc/pastposix-functions/gcvt.texi |  5 +--
 doc/pastposix-functions/getwd.texi|  7 ++--
 doc/pastposix-functions/index.texi|  5 +--
 doc/pastposix-functions/mktemp.texi   |  5 +--
 doc/pastposix-functions/rindex.texi   |  5 +--
 doc/pastposix-functions/wcswcs.texi   |  5 +--
 doc/posix-functions/_longjmp.texi |  8 ++---
 doc/posix-functions/_setjmp.texi  |  8 ++---
 doc/posix-functions/_tolower.texi |  6 ++--
 doc/posix-functions/_toupper.texi |  6 ++--
 doc/posix-functions/asctime_r.texi|  8 ++---
 doc/posix-functions/ctime_r.texi  |  8 ++---
 doc/posix-functions/gets.texi | 10 +++---
 doc/posix-functions/gettimeofday.texi |  6 ++--
 doc/posix-functions/isascii.texi  |  6 ++--
 .../pthread_getconcurrency.texi   |  6 ++--
 .../pthread_setconcurrency.texi   |  6 ++--
 doc/posix-functions/rand_r.texi   |  6 ++--
 doc/posix-functions/setpgrp.texi  |  6 ++--
 doc/posix-functions/sighold.texi  |  6 ++--
 doc/posix-functions/sigignore.texi|  6 ++--
 doc/posix-functions/siginterrupt.texi |  6 ++--
 doc/posix-functions/sigpause.texi |  6 ++--
 doc/posix-functions/sigrelse.texi |  6 ++--
 doc/posix-functions/sigset.texi   |  6 ++--
 doc/posix-functions/tempnam.texi  |  6 ++--
 doc/posix-functions/ulimit.texi   |  6 ++--
 doc/posix-functions/utime.texi|  6 ++--
 doc/posix-headers/stropts.texi|  5 ++-
 doc/posix-headers/trace.texi  |  5 ++-
 doc/posix-headers/ulimit.texi |  5 ++-
 doc/posix-headers/utime.texi  |  5 ++-
 lib/getopt.c  |  2 +-
 lib/glob-libc.h   |  2 +-
 64 files changed, 203 insertions(+), 141 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 25e150a59a..e09ff2a234 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2024-05-23  Paul Eggert  
+
+   POSIX.1-2024 has been approved
+   It hasn’t been published yet, so just fix documentation talking
+   about “draft” POSIX, about particular POSIX versions, etc.
+   More work will need to be done once it’s published on the web,
+   to update URLs, and better document new and changed interfaces.
+
 2024-05-23  Bruno Haible  
 
mbrtoc32: Strengthen tests.
diff --git a/MODULES.html.sh b/MODULES.html.sh
index 442be7f690..4df6497fc3 100755
--- a/MODULES.html.sh
+++ b/MODULES.html.sh
@@ -21,8 +21,8 @@
 # Extend the PATH so that gnulib-tool is found.
 PATH=`dirname "$0"`:$PATH; export PATH
 
-POSIX2001_URL='https://pubs.opengroup.org/onlinepubs/009695399'
-POSIX2008_URL='https://pubs.opengroup.org/onlinepubs/9699919799'
+POSIX2004_URL='https://pubs.opengroup.org/onlinepubs/009695399'
+POSIX2017_URL='https://pubs.opengroup.org/

[PATCH] c-strtod: include

2024-05-22 Thread Paul Eggert
* lib/c-strtod.c: Include , since we call sprintf.
Problem found by Oracle Developer Studio 12.6 on Solaris 10.
---
 ChangeLog  | 6 ++
 lib/c-strtod.c | 1 +
 2 files changed, 7 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index f94a39a2bb..1c85c92f9f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2024-05-21  Paul Eggert  
+
+   c-strtod: include 
+   * lib/c-strtod.c: Include , since we call sprintf.
+   Problem found by Oracle Developer Studio 12.6 on Solaris 10.
+
 2024-05-21  Collin Funk  
 
getusershell: Split file by lines instead of spaces.
diff --git a/lib/c-strtod.c b/lib/c-strtod.c
index 9551aebe37..4089ccd79b 100644
--- a/lib/c-strtod.c
+++ b/lib/c-strtod.c
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-- 
2.45.1




[PATCH] boot-time: port to Alpine 3.20.0_rc2

2024-05-21 Thread Paul Eggert
* lib/boot-time-aux.h (get_openbsd_boot_time):
Port to Alpine Linux, which had bogus timestamps on /var/run/utmp.
---
 ChangeLog   |  6 ++
 lib/boot-time-aux.h | 12 ++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 099a249271..0baff3aecc 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2024-05-21  Paul Eggert  
+
+   boot-time: port to Alpine 3.20.0_rc2
+   * lib/boot-time-aux.h (get_openbsd_boot_time):
+   Port to Alpine Linux, which had bogus timestamps on /var/run/utmp.
+
 2024-05-21  Bruno Haible  
 
trim tests: Avoid test failure on Solaris 11 OmniOS.
diff --git a/lib/boot-time-aux.h b/lib/boot-time-aux.h
index 7f8c5405e4..b1add30239 100644
--- a/lib/boot-time-aux.h
+++ b/lib/boot-time-aux.h
@@ -108,8 +108,16 @@ get_linux_boot_time_fallback (struct timespec *p_boot_time)
   struct stat statbuf;
   if (stat (filename, ) >= 0)
 {
-  *p_boot_time = get_stat_mtime ();
-  return 0;
+  struct timespec boot_time = get_stat_mtime ();
+  /* On Alpine 3.20.0_rc2 /var/run/utmp was observed with bogus
+ timestamps of ~10 s.  Reject timestamps before
+ 2005-07-25 23:34:15 UTC (1122334455), as neither Alpine
+ nor Devuan existed then.  */
+  if (boot_time.tv_sec >= 1122334455)
+{
+  *p_boot_time = boot_time;
+  return 0;
+}
 }
 }
   return -1;
-- 
2.45.1




Re: [PATCH] getopt-posix: port better to Alpine 3.20.0_rc1

2024-05-21 Thread Paul Eggert

On 2024-05-21 09:34, Bruno Haible wrote:

configure.ac:43: warning: AC_REQUIRE: 'gl_CHECK_HEADER_SYS_CDEFS_H' was 
expanded before it was required
configure.ac:43:https://www.gnu.org/software/autoconf/manual/autoconf.html#Expanded-Before-Required


Thanks, I had missed that in all the 'bootstrap' output. I updated 
diffutils to use the latest gnulib.


Sometimes I wish 'bootstrap' and 'configure' were less chatty.



[PATCH] getopt-posix: port better to Alpine 3.20.0_rc1

2024-05-20 Thread Paul Eggert
Alpine’s  is a stub that issues a deprecation #warning.
* m4/getopt.m4 (gl_GETOPT_SUBSTITUTE_HEADER):
* m4/sched_h.m4 (gl_SCHED_H): Use the new macro
gl_CHECK_HEADER_SYS_CDEFS_H instead of checking independently.
* m4/sys_cdefs_h.m4: New file.
* modules/getopt-posix, modules/sched (Files): Add m4/sys_cdefs_h.m4.
---
 ChangeLog| 10 ++
 m4/getopt.m4 | 11 ++-
 m4/sched_h.m4| 12 +++-
 m4/sys_cdefs_h.m4| 25 +
 modules/getopt-posix |  1 +
 modules/sched|  1 +
 6 files changed, 42 insertions(+), 18 deletions(-)
 create mode 100644 m4/sys_cdefs_h.m4

diff --git a/ChangeLog b/ChangeLog
index dd5b0c4c66..2e82a08042 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2024-05-20  Paul Eggert  
+
+   getopt-posix: port better to Alpine 3.20.0_rc1
+   Alpine’s  is a stub that issues a deprecation #warning.
+   * m4/getopt.m4 (gl_GETOPT_SUBSTITUTE_HEADER):
+   * m4/sched_h.m4 (gl_SCHED_H): Use the new macro
+   gl_CHECK_HEADER_SYS_CDEFS_H instead of checking independently.
+   * m4/sys_cdefs_h.m4: New file.
+   * modules/getopt-posix, modules/sched (Files): Add m4/sys_cdefs_h.m4.
+
 2024-05-20  Collin Funk  
 
tests: Update expected tests results on NetBSD.
diff --git a/m4/getopt.m4 b/m4/getopt.m4
index 297722eae4..53cab8bef9 100644
--- a/m4/getopt.m4
+++ b/m4/getopt.m4
@@ -1,5 +1,5 @@
 # getopt.m4
-# serial 49
+# serial 50
 dnl Copyright (C) 2002-2006, 2008-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,
@@ -366,14 +366,7 @@ dnl is ambiguous with environment values that contain 
newlines.
 
 AC_DEFUN([gl_GETOPT_SUBSTITUTE_HEADER],
 [
-  AC_CHECK_HEADERS_ONCE([sys/cdefs.h])
-  if test $ac_cv_header_sys_cdefs_h = yes; then
-HAVE_SYS_CDEFS_H=1
-  else
-HAVE_SYS_CDEFS_H=0
-  fi
-  AC_SUBST([HAVE_SYS_CDEFS_H])
-
+  gl_CHECK_HEADER_SYS_CDEFS_H
   AC_DEFINE([__GETOPT_PREFIX], [[rpl_]],
 [Define to rpl_ if the getopt replacement functions and variables
  should be used.])
diff --git a/m4/sched_h.m4 b/m4/sched_h.m4
index 1e022948b5..61c202ef0c 100644
--- a/m4/sched_h.m4
+++ b/m4/sched_h.m4
@@ -1,5 +1,5 @@
 # sched_h.m4
-# serial 15
+# serial 16
 dnl Copyright (C) 2008-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,
@@ -15,7 +15,8 @@ AC_DEFUN_ONCE([gl_SCHED_H],
 
   AC_REQUIRE([AC_CANONICAL_HOST])
 
-  AC_CHECK_HEADERS_ONCE([sys/cdefs.h])
+  AC_REQUIRE([gl_CHECK_HEADER_SYS_CDEFS_H])
+
   AC_CHECK_HEADERS([sched.h], [], [],
 [[#if HAVE_SYS_CDEFS_H
#include 
@@ -57,13 +58,6 @@ AC_DEFUN_ONCE([gl_SCHED_H],
   fi
   AC_SUBST([HAVE_STRUCT_SCHED_PARAM])
 
-  if test "$ac_cv_header_sys_cdefs_h" = yes; then
-HAVE_SYS_CDEFS_H=1
-  else
-HAVE_SYS_CDEFS_H=0
-  fi
-  AC_SUBST([HAVE_SYS_CDEFS_H])
-
   dnl Ensure the type pid_t gets defined.
   AC_REQUIRE([AC_TYPE_PID_T])
 
diff --git a/m4/sys_cdefs_h.m4 b/m4/sys_cdefs_h.m4
new file mode 100644
index 00..069146d438
--- /dev/null
+++ b/m4/sys_cdefs_h.m4
@@ -0,0 +1,25 @@
+# sys_cdefs_h.m4 - Is  compatible enough with glibc?
+# serial 1
+dnl Copyright 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,
+dnl with or without modifications, as long as this notice is preserved.
+
+dnl Written by Paul Eggert.
+
+AC_DEFUN([gl_CHECK_HEADER_SYS_CDEFS_H],
+  [AC_CACHE_CHECK([for glibc-compatible sys/cdefs.h],
+ [gl_cv_header_sys_cdefs_h],
+ [AC_COMPILE_IFELSE(
+[AC_LANG_DEFINES_PROVIDED
+ [#include 
+  enum { foo = __GNUC_PREREQ (14, 1) } bar;
+]],
+[gl_cv_header_sys_cdefs_h=yes],
+[gl_cv_header_sys_cdefs_h=no])])
+   if test "$gl_cv_header_sys_cdefs_h" = yes; then
+ HAVE_SYS_CDEFS_H=1
+   else
+ HAVE_SYS_CDEFS_H=0
+   fi
+   AC_SUBST([HAVE_SYS_CDEFS_H])])
diff --git a/modules/getopt-posix b/modules/getopt-posix
index 6305e83c8a..0b50620c4b 100644
--- a/modules/getopt-posix
+++ b/modules/getopt-posix
@@ -12,6 +12,7 @@ lib/getopt-pfx-core.h
 lib/getopt-pfx-ext.h
 lib/getopt_int.h
 m4/getopt.m4
+m4/sys_cdefs_h.m4
 
 Depends-on:
 unistd
diff --git a/modules/sched b/modules/sched
index 042aa8be04..7ce972adf7 100644
--- a/modules/sched
+++ b/modules/sched
@@ -5,6 +5,7 @@ Files:
 lib/sched.in.h
 m4/sched_h.m4
 m4/pid_t.m4
+m4/sys_cdefs_h.m4
 
 Depends-on:
 gen-header
-- 
2.45.1




Re: byteswap side-effect defect report from Coverity

2024-05-20 Thread Paul Eggert

On 5/20/24 14:29, Jeffrey Walton wrote:

I think this is a valid finding. It will operate one way in release builds
(-DNDEBUG), and another way in debug builds (no NDEBUG).

When NDEBUG is in effect, the code `bswap_16 (value_1++) == 0` will be
removed.


How so? The test program uses 'ASSERT' not 'assert', so 'NDEBUG' should 
be irrelevant.


Can you reproduce the problem with:

./gnulib-tool --test byteswap

?





Re: byteswap side-effect defect report from Coverity

2024-05-20 Thread Paul Eggert

On 5/20/24 12:15, Collin Funk wrote:

I just learned what a Coverity scan is. Do I have to have
permission to view the defects?


I think anybody can sign up, here:

https://scan.coverity.com/projects/gnu-gnulib



[PATCH] byteswap: fix problem on macOS

2024-05-20 Thread Paul Eggert
* m4/byteswap.m4 (gl_BYTESWAP): Quote a variable that might not
be defined (or the user may have defined it to something with spaces!).
Problem reported by Mattias Engdegård for Emacs on macOS.
---
 ChangeLog  | 5 +
 m4/byteswap.m4 | 4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index ea799492a1..88258bec2c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
 2024-05-20  Paul Eggert  
 
+   byteswap: fix problem on macOS
+   * m4/byteswap.m4 (gl_BYTESWAP): Quote a variable that might not
+   be defined (or the user may have defined it to something with spaces!).
+   Problem reported by Mattias Engdegård for Emacs on macOS.
+
linkat-tests: fix up assertion-failure changes
* tests/test-linkat.c (main): Don’t lose the failure results of
earlier tests.  Problem found by Coverity.
diff --git a/m4/byteswap.m4 b/m4/byteswap.m4
index 3185bab763..e91da97b95 100644
--- a/m4/byteswap.m4
+++ b/m4/byteswap.m4
@@ -1,5 +1,5 @@
 # byteswap.m4
-# serial 6
+# serial 7
 dnl Copyright (C) 2005, 2007, 2009-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,
@@ -33,7 +33,7 @@ AC_DEFUN([gl_BYTESWAP],
  [gl_cv_header_working_byteswap_h=no])
   ])
   fi
-  if test $gl_cv_header_working_byteswap_h = yes; then
+  if test "$gl_cv_header_working_byteswap_h" = yes; then
 GL_GENERATE_BYTESWAP_H=false
   else
 GL_GENERATE_BYTESWAP_H=true
-- 
2.40.1




[PATCH 1/2] dfa: attempt to pacify Coverity

2024-05-20 Thread Paul Eggert
* lib/dfa.c (lex): Use ‘assume’ rather than ‘abort’,
to try to pacify Coverity.
(maybe_disable_superset_dfa): Use ‘assume’ here too, for consistency.
Using ‘assume’ should make the code a tiny bit faster, though
at the cost of having undefined behavior instead of nicely aborting.
---
 ChangeLog | 9 +
 lib/dfa.c | 5 ++---
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index a138378822..997f51f3b5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2024-05-20  Paul Eggert  
+
+   dfa: attempt to pacify Coverity
+   * lib/dfa.c (lex): Use ‘assume’ rather than ‘abort’,
+   to try to pacify Coverity.
+   (maybe_disable_superset_dfa): Use ‘assume’ here too, for consistency.
+   Using ‘assume’ should make the code a tiny bit faster, though
+   at the cost of having undefined behavior instead of nicely aborting.
+
 2024-05-20  Bruno Haible  
 
Make it easy to generate debug info for libbacktrace on macOS.
diff --git a/lib/dfa.c b/lib/dfa.c
index c79afddcd9..0ccb167176 100644
--- a/lib/dfa.c
+++ b/lib/dfa.c
@@ -1221,8 +1221,7 @@ lex (struct dfa *dfa)
 {
   /* This loop should consume at most a backslash and some other
  character.  */
-  if (2 <= i)
-abort ();
+  assume (i < 2);
 
   if (! dfa->lex.left)
 return dfa->lex.lasttok = END;
@@ -3727,7 +3726,7 @@ maybe_disable_superset_dfa (struct dfa *d)
 {
 case ANYCHAR:
   /* Lowered.  */
-  abort ();
+  assume (false);
 case BACKREF:
   have_backref = true;
   break;
-- 
2.40.1




[PATCH 2/2] linkat-tests: fix up assertion-failure changes

2024-05-20 Thread Paul Eggert
* tests/test-linkat.c (main): Don’t lose the failure results of
earlier tests.  Problem found by Coverity.
---
 ChangeLog   |  4 
 tests/test-linkat.c | 15 +--
 2 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 997f51f3b5..ea799492a1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
 2024-05-20  Paul Eggert  
 
+   linkat-tests: fix up assertion-failure changes
+   * tests/test-linkat.c (main): Don’t lose the failure results of
+   earlier tests.  Problem found by Coverity.
+
dfa: attempt to pacify Coverity
* lib/dfa.c (lex): Use ‘assume’ rather than ‘abort’,
to try to pacify Coverity.
diff --git a/tests/test-linkat.c b/tests/test-linkat.c
index c3efb5df60..04814ddd1b 100644
--- a/tests/test-linkat.c
+++ b/tests/test-linkat.c
@@ -141,7 +141,7 @@ main (void)
   /* Skip the rest of the test if the file system does not support hard links
  and symlinks.  */
   if (result)
-return result;
+return test_exit_status ? test_exit_status : result;
 
   /* Create locations to manipulate.  */
   ASSERT (mkdir (BASE "sub1", 0700) == 0);
@@ -202,10 +202,13 @@ main (void)
   ASSERT (rmdir (BASE "sub1") == 0);
   ASSERT (rmdir (BASE "sub2") == 0);
   free (cwd);
-  if (!result)
-fputs ("skipping test: symlinks not supported on this file system\n",
-   stderr);
-  return result;
+  if (!test_exit_status)
+{
+  fputs ("skipping test: symlinks not supported on this file system\n",
+ stderr);
+  return 77;
+}
+  return test_exit_status;
 }
   dfd = open (".", O_RDONLY);
   ASSERT (0 <= dfd);
@@ -384,5 +387,5 @@ main (void)
   ASSERT (unlink (BASE "link5") == 0);
   free (cwd);
 
-  return (result ? result : test_exit_status);
+  return test_exit_status;
 }
-- 
2.40.1




byteswap side-effect defect report from Coverity

2024-05-20 Thread Paul Eggert
Bruno and I get defect reports from Coverity Scan for Gnulib. The most 
recent one has this new complaint:



*** CID 1588680:  Incorrect expression  (ASSERT_SIDE_EFFECT)
/gltests/test-byteswap.c: 43 in test_bswap_eval_once()
37 
38 /* Test that the bswap functions evaluate their arguments once.  */

39 static void
40 test_bswap_eval_once (void)
41 {
42   uint_least16_t value_1 = 0;

>>> CID 1588680:  Incorrect expression  (ASSERT_SIDE_EFFECT)
>>> Argument "value_1++" of ASSERT() has a side effect.  The containing 
function might work differently in a non-debug build.

43   ASSERT (bswap_16 (value_1++) == 0);


I checked the glibc sources, and long ago glibc indeed had a bug in this 
area: bswap_16 and related function-like macros evaluated their 
arguments more than once. This bug was fixed in the following glibc 
commit dated Sat Aug 8 20:02:34 1998 +, and the fix appears in glibc 
2.1 (1999).


https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=7ce241a03e2c0b49482d9d05c8ddb765e89a01d9


Gnulib does not support glibc 2.1.x and older, so this should not be a 
problem when porting to glibc. However, I worried that other platforms 
might have the bug, until I noticed that m4/byteswap.m4 already 
inadvertently tests for it. I installed the attached patch to document 
the test.


We can ignore this Coverity defect report as a false positive, just as 
we ignore many other defect reports.From 6dbbada2b05bdc5efd0a5592a7805c92fe0531c6 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 20 May 2024 09:08:27 -0700
Subject: [PATCH] * m4/byteswap.m4: Add comment about broken C libraries.

---
 m4/byteswap.m4 | 4 
 1 file changed, 4 insertions(+)

diff --git a/m4/byteswap.m4 b/m4/byteswap.m4
index 3f5ef45cfe..3185bab763 100644
--- a/m4/byteswap.m4
+++ b/m4/byteswap.m4
@@ -15,6 +15,10 @@ AC_DEFUN([gl_BYTESWAP],
 AC_CACHE_CHECK([for working bswap_16, bswap_32, bswap_64],
   [gl_cv_header_working_byteswap_h],
   [gl_cv_header_working_byteswap_h=no
+   dnl Check that floating point arguments work.
+   dnl This also checks C libraries with implementations like
+   dnl '#define bswap_16(x) (((x) >> 8 & 0xff) | (((x) & 0xff) << 8))'
+   dnl that mistakenly evaluate their arguments multiple times.
AC_COMPILE_IFELSE(
  [AC_LANG_PROGRAM(
 [[#include 
-- 
2.40.1



Re: [PATCH] sha512-buffer: port back to 32-bit-only hosts

2024-05-19 Thread Paul Eggert

On 2024-05-19 14:37, Bruno Haible wrote:

uintN_t arithmetic is overflow-free, just like 'unsigned int' arithmetic.


Not exactly. For example, this:

  uint16_t a = 46341, b = a * a;

has undefined behavior on typical platforms with 32-bit int, because 
46341*46341 exceeds 2**31 - 1. Although many programmers would consider 
this an example of uint16_t arithmetic, something else is going on.


If uintN_t fits in int, a program cannot do uintN_t arithmetic directly, 
as values are promoted to int before they become arithmetic operands. A 
program can do only int arithmetic on these values, and the int 
arithmetic can overflow.


This can happen in C23 even if you're just adding 1, instead of 
multiplying. For example:


  unsigned _BitInt(31) n = 0x7fff, o = 1, p = n + o;

has undefined behavior on typical platforms with 32-bit int, even though 
n and o are both unsigned.


A similar problem with adding 1 can also occur in C17 and earlier; at 
least one legacy platform (the Unisys Libra) has INT_MAX == UINT_MAX, so 
UINT_MAX + 1u has undefined behavior.


Similarly, fully portable code can't rely on standard-defined unsigned 
types like size_t overflowing nicely, as the overflow might trap if 
size_t fits in int. Admittedly any platform that traps on size_t 
overflow would be unpopular - but the standards allow it and arguably 
some buggy apps would benefit by trapping right away rather than 
crashing later.


Unsigned int, unsigned long int, unsigned long long int, and uintmax_t 
are the only types where fully portable code can assume wraparound overflow.




instead
of using the 'u64' module in order to avoid uint64_t, it would be much
simpler to make  define the missing int64_t and uint64_t types


We could do something along those lines. I'd prefer it, though, if we 
did that only on platforms where we tested that 'unsigned long long int' 
is actually 64 bits, since the relevant code is already cautious in this 
area due to concerns such as the above. Although platforms are currently 
leery of integers wider than 64 bits, wider integers are commonly 
supported under the covers now, and I expect it won't be forever before 
they emerge from the shadows.




Re: [PATCH] sha512-buffer: port back to 32-bit-only hosts

2024-05-19 Thread Paul Eggert

On 2024-05-18 20:42, Collin Funk wrote:

Out of personal interest, do you happen to know what platforms Emacs
builds on that lack 64-bit types?


Emacs is a bit of a special case as it builds on verrry ooold platforms, 
including platforms no longer supported by their suppliers, and we're 
reasonably reluctant to require uint64_t except in platform-specific 
code where we know it's available. For example, there have been fairly 
recent (circa 2023) additions to Emacs working around the lack of 
uint64_t on older Android in certain compilation environments. For an 
example of these old environment's hassles (having to do with c89 vs c99 
compatibility, ouch), see 
 
which indicates this was an issue through at least Android Jelly Bean 
(2012), and I think the problem was even worse in earlier Android versions.


For what it's worth, in theory one must be careful with all the uint*_t 
types, as the standards say that integer overflow can have undefined 
behavior with any of them (because in theory they could all fit in 
'int'). One can use stdckdint.h macros to work around this theoretical 
issue, but of course that's annoying. I often find it easier just to use 
'unsigned int' or something wider.




[PATCH] sha512-buffer: port back to 32-bit-only hosts

2024-05-18 Thread Paul Eggert
Port to platforms lacking 64-bit integers (something that Emacs
still attempts to do, in theory) by adding an u64bswap primitive
to u64.h and using that, instead of using bswap_64.  This fixes a
bug I made in commit 0d45ec7c033c165ad73a6509c7fa84aa67edf4ea
dated Sun Jun 17 14:35:37 2018 -0700.
* lib/sha512.c (SWAP): Use u64bswap, not bswap_64, to port
to older platforms lacking 64-bit integers.
* lib/u64.h: Include stddef.h, for size_t.
Include byteswap.h, for bswap_64 (on platforms with 64-bit int),
bswap_32.
(u64rol): Now a function, not a macro, so that it evaluates
its args only once.
(u64uint32): New typedef.
(u64, u64hilo, u64lo): Use it.
(_GL_U64_MASK32): New macro.
(u64size, u64plus, u64shl, u64shr, u64plus): Use it as needed for
odd platforms where unsigned int is wider than 32 bits.
(u64lt): Return bool, not int.
* modules/u64 (Depends-on): Add byteswap, stdbool.
* tests/test-u64.c (main): Test u64bswap.
---
 ChangeLog| 24 +++
 lib/sha512.c |  2 +-
 lib/u64.h| 60 
 modules/u64  |  2 ++
 tests/test-u64.c |  7 ++
 5 files changed, 74 insertions(+), 21 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index fc2c42283c..b7f62031f3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,27 @@
+2024-05-18  Paul Eggert  
+
+   sha512-buffer: port back to 32-bit-only hosts
+   Port to platforms lacking 64-bit integers (something that Emacs
+   still attempts to do, in theory) by adding an u64bswap primitive
+   to u64.h and using that, instead of using bswap_64.  This fixes a
+   bug I made in commit 0d45ec7c033c165ad73a6509c7fa84aa67edf4ea
+   dated Sun Jun 17 14:35:37 2018 -0700.
+   * lib/sha512.c (SWAP): Use u64bswap, not bswap_64, to port
+   to older platforms lacking 64-bit integers.
+   * lib/u64.h: Include stddef.h, for size_t.
+   Include byteswap.h, for bswap_64 (on platforms with 64-bit int),
+   bswap_32.
+   (u64rol): Now a function, not a macro, so that it evaluates
+   its args only once.
+   (u64uint32): New typedef.
+   (u64, u64hilo, u64lo): Use it.
+   (_GL_U64_MASK32): New macro.
+   (u64size, u64plus, u64shl, u64shr, u64plus): Use it as needed for
+   odd platforms where unsigned int is wider than 32 bits.
+   (u64lt): Return bool, not int.
+   * modules/u64 (Depends-on): Add byteswap, stdbool.
+   * tests/test-u64.c (main): Test u64bswap.
+
 2024-05-18  Collin Funk  
 
dup3: Update documentation and expected test results.
diff --git a/lib/sha512.c b/lib/sha512.c
index 9eb036fb32..6750041bc7 100644
--- a/lib/sha512.c
+++ b/lib/sha512.c
@@ -35,7 +35,7 @@
 #ifdef WORDS_BIGENDIAN
 # define SWAP(n) (n)
 #else
-# define SWAP(n) bswap_64 (n)
+# define SWAP(n) u64bswap (n)
 #endif
 
 #if ! HAVE_OPENSSL_SHA512
diff --git a/lib/u64.h b/lib/u64.h
index 4eca03e985..cfb5588757 100644
--- a/lib/u64.h
+++ b/lib/u64.h
@@ -22,8 +22,11 @@
  #error "Please include config.h first."
 #endif
 
+#include 
 #include 
 
+#include 
+
 _GL_INLINE_HEADER_BEGIN
 #ifndef _GL_U64_INLINE
 # define _GL_U64_INLINE _GL_INLINE
@@ -34,9 +37,6 @@ extern "C" {
 #endif
 
 
-/* Return X rotated left by N bits, where 0 < N < 64.  */
-#define u64rol(x, n) u64or (u64shl (x, n), u64shr (x, 64 - n))
-
 #ifdef UINT64_MAX
 
 /* Native implementations are trivial.  See below for comments on what
@@ -53,24 +53,30 @@ typedef uint64_t u64;
 # define u64plus(x, y) ((x) + (y))
 # define u64shl(x, n) ((x) << (n))
 # define u64shr(x, n) ((x) >> (n))
+# define u64bswap(x) bswap_64 (x)
 
 #else
 
-/* u64 is a 64-bit unsigned integer value.
+# define _GL_U64_MASK32 0xul /* 2**32 - 1.  */
+
+/* u64 represents a 64-bit unsigned integer value equal to (HI << 32) + LO.
+   Implement it with unsigned int, which the GNU coding standards say
+   is wide enough to hold 32 bits, and which does not signal an error
+   when adding (theoretically possible with types like uint_fast32_t).
u64init (HI, LO), is like u64hilo (HI, LO), but for use in
initializer contexts.  */
 # ifdef WORDS_BIGENDIAN
-typedef struct { uint32_t hi, lo; } u64;
+typedef struct { unsigned int hi, lo; } u64;
 #  define u64init(hi, lo) { hi, lo }
 # else
-typedef struct { uint32_t lo, hi; } u64;
+typedef struct { unsigned int lo, hi; } u64;
 #  define u64init(hi, lo) { lo, hi }
 # endif
 
 /* Given the high and low-order 32-bit quantities HI and LO, return a u64
value representing (HI << 32) + LO.  */
 _GL_U64_INLINE u64
-u64hilo (uint32_t hi, uint32_t lo)
+u64hilo (unsigned int hi, unsigned int lo)
 {
   u64 r;
   r.hi = hi;
@@ -78,9 +84,9 @@ u64hilo (uint32_t hi, uint32_t lo)
   return r;
 }
 
-/* Return a u64 value representing LO.  */
+/* Return a u64 value representing the 32-bit quantity LO.  */
 _GL_U64_INLINE u64
-u64lo (uint32_t lo)
+u64lo (unsigned int lo)
 {
   u64 r;
   r.hi = 0;
@@ -88,18 +94,18 @@ u64lo (uint32_t lo)
   

Re: [PATCH] byteswap: port better to limited platforms

2024-05-18 Thread Paul Eggert

On 2024-05-17 16:51, Bruno Haible wrote:

-- foo.c --
unsigned long long x = 0xff00;
---

$ gcc -Wall -S foo.c
foo.c:1: warning: integer constant is too large for ‘long’ type


I don't see how that would produce incorrect code for byteswap.h.

If memory serves, GCC formerly warned about integer constants that had a 
"surprising" type, for a definition of "surprising" that was too 
generous so that there were too many false alarms.


The longer story is C89 lacked 'long long'. Also, in C89 on a 32-bit int 
platform the decimal integer literal 2147483648 had type 'unsigned int' 
because 2147483648 fits in 'unsigned int' but not plain 'int'. Although 
this misfeature was fixed in C99 it was present in many compilers for 
some time after that. (It still seems to be present in MS Visual Studio! 
See 
<https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-2-c4146?view=msvc-170>.)


To help write portable code, GCC formerly warned about integer constants 
that might not be portable to C89, but it then went ahead and produced 
correct code.


The need for these warnings went away long ago (except perhaps for 
Microsoft...) but they can be annoying so I installed the attached patch 
to pacify older GCCs.



PS. We could simplify the code by removing all uses of __builtin_bswap64 
etc. Although these uses are present only to improve performance, they 
do not improve performance with GCC 14 x86-64 with -O2.From 221d026428e20d18faf96b0e38b25f4d89d32805 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 18 May 2024 07:48:47 -0700
Subject: [PATCH] byteswap: pacify GCC 4.4.7 and older

Problem reported by Bruno Haible in:
https://lists.gnu.org/r/bug-gnulib/2024-05/msg00277.html
* lib/byteswap.in.h (bswap_16, bswap_32, bswap_64):
Compute the mask rather than using long constants like
0xff00 that may generate bogus warnings.
---
 ChangeLog |  9 +
 lib/byteswap.in.h | 31 +--
 2 files changed, 26 insertions(+), 14 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 29adf56ab7..79f813e1b2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2024-05-18  Paul Eggert  
+
+	byteswap: pacify GCC 4.4.7 and older
+	Problem reported by Bruno Haible in:
+	https://lists.gnu.org/r/bug-gnulib/2024-05/msg00277.html
+	* lib/byteswap.in.h (bswap_16, bswap_32, bswap_64):
+	Compute the mask rather than using long constants like
+	0xff00 that may generate bogus warnings.
+
 2024-05-18  Bruno Haible  
 
 	endian tests: Verify that it can be used from C++.
diff --git a/lib/byteswap.in.h b/lib/byteswap.in.h
index 0e760005c2..4be335d915 100644
--- a/lib/byteswap.in.h
+++ b/lib/byteswap.in.h
@@ -62,8 +62,9 @@ bswap_16 (uint_least16_t x)
 #ifdef _GL_BYTESWAP_HAS_BUILTIN_BSWAP16
   return __builtin_bswap16 (x);
 #else
-  return (  (x & 0xff00) >> 8
-  | (x & 0x00ff) << 8);
+  uint_fast16_t mask = 0xff;
+  return (  (x & mask << 8 * 1) >> 8 * 1
+  | (x & mask << 8 * 0) << 8 * 1);
 #endif
 }
 
@@ -75,10 +76,11 @@ bswap_32 (uint_least32_t x)
 #ifdef _GL_BYTESWAP_HAS_BUILTIN_BSWAP32
   return __builtin_bswap32 (x);
 #else
-  return (  (x & 0xff00) >> 24
-  | (x & 0x00ff) >>  8
-  | (x & 0xff00) <<  8
-  | (x & 0x00ff) << 24);
+  uint_fast32_t mask = 0xff;
+  return (  (x & mask << 8 * 3) >> 8 * 3
+  | (x & mask << 8 * 2) >> 8 * 1
+  | (x & mask << 8 * 1) << 8 * 1
+  | (x & mask << 8 * 0) << 8 * 3);
 #endif
 }
 
@@ -91,14 +93,15 @@ bswap_64 (uint_least64_t x)
 # ifdef _GL_BYTESWAP_HAS_BUILTIN_BSWAP64
   return __builtin_bswap64 (x);
 # else
-  return (  (x & 0xff00) >> 56
-  | (x & 0x00ff) >> 40
-  | (x & 0xff00) >> 24
-  | (x & 0x00ff) >>  8
-  | (x & 0xff00) <<  8
-  | (x & 0x00ff) << 24
-  | (x & 0xff00) << 40
-  | (x & 0x00ff) << 56);
+  uint_fast64_t mask = 0xff;
+  return (  (x & mask << 8 * 7) >> 8 * 7
+  | (x & mask << 8 * 6) >> 8 * 5
+  | (x & mask << 8 * 5) >> 8 * 3
+  | (x & mask << 8 * 4) >> 8 * 1
+  | (x & mask << 8 * 3) << 8 * 1
+  | (x & mask << 8 * 2) << 8 * 3
+  | (x & mask << 8 * 1) << 8 * 5
+  | (x & mask << 8 * 0) << 8 * 7);
 # endif
 }
 #endif
-- 
2.40.1



[PATCH] byteswap: port better to limited platforms

2024-05-17 Thread Paul Eggert
POSIX does not require uint64_t, and the C standard
does not require uint16_t or uint32_t either, so port
to platforms that lack these types.  The POSIX limitation
is the only significant one in practice.  I ran into this
issue when updating Emacs, which still ports to platforms
lacking 64-bit types.
* lib/byteswap.in.h (bswap_16, bswap_32, bswap_64):
Accept and return uint_leastN_t instead of uintN_t,
for portability to non-POSIX hosts that lack uintN_t.
Almost no platforms these days lack the types, but
it’s easy to port so let’s do that.  Also, redo to avoid
unnecssary parentheses, as these are now functions not macros.
(bswap_64): Define only if UINT_LEAST64_MAX, for benefit
of not-quite-C99 platforms.  This is similar to what
bitrotate.h does.
* tests/test-byteswap.c (test_bswap_constant)
(test_bswap_eval_once, test_bswap_double) [!UINT_LEAST64_MAX]:
Do not test 64-bit swaps.
---
 ChangeLog | 22 +
 lib/byteswap.in.h | 45 ---
 tests/test-byteswap.c | 20 ---
 3 files changed, 60 insertions(+), 27 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 5207f25b3a..078aea49cf 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,25 @@
+2024-05-17  Paul Eggert  
+
+   byteswap: port better to limited platforms
+   POSIX does not require uint64_t, and the C standard
+   does not require uint16_t or uint32_t either, so port
+   to platforms that lack these types.  The POSIX limitation
+   is the only significant one in practice.  I ran into this
+   issue when updating Emacs, which still ports to platforms
+   lacking 64-bit types.
+   * lib/byteswap.in.h (bswap_16, bswap_32, bswap_64):
+   Accept and return uint_leastN_t instead of uintN_t,
+   for portability to non-POSIX hosts that lack uintN_t.
+   Almost no platforms these days lack the types, but
+   it’s easy to port so let’s do that.  Also, redo to avoid
+   unnecssary parentheses, as these are now functions not macros.
+   (bswap_64): Define only if UINT_LEAST64_MAX, for benefit
+   of not-quite-C99 platforms.  This is similar to what
+   bitrotate.h does.
+   * tests/test-byteswap.c (test_bswap_constant)
+   (test_bswap_eval_once, test_bswap_double) [!UINT_LEAST64_MAX]:
+   Do not test 64-bit swaps.
+
 2024-05-17  Bruno Haible  
 
stdbit-h: Fix leading-zeros/ones functions on 64-bit MSVC.
diff --git a/lib/byteswap.in.h b/lib/byteswap.in.h
index ae05d59441..0e760005c2 100644
--- a/lib/byteswap.in.h
+++ b/lib/byteswap.in.h
@@ -56,47 +56,52 @@ extern "C" {
 
 /* Given an unsigned 16-bit argument X, return the value corresponding to
X with reversed byte order.  */
-_GL_BYTESWAP_INLINE uint16_t
-bswap_16 (uint16_t x)
+_GL_BYTESWAP_INLINE uint_least16_t
+bswap_16 (uint_least16_t x)
 {
 #ifdef _GL_BYTESWAP_HAS_BUILTIN_BSWAP16
   return __builtin_bswap16 (x);
 #else
-  return (x) >> 8) & 0xff) | (((x) & 0xff) << 8)));
+  return (  (x & 0xff00) >> 8
+  | (x & 0x00ff) << 8);
 #endif
 }
 
 /* Given an unsigned 32-bit argument X, return the value corresponding to
X with reversed byte order.  */
-_GL_BYTESWAP_INLINE uint32_t
-bswap_32 (uint32_t x)
+_GL_BYTESWAP_INLINE uint_least32_t
+bswap_32 (uint_least32_t x)
 {
 #ifdef _GL_BYTESWAP_HAS_BUILTIN_BSWAP32
   return __builtin_bswap32 (x);
 #else
-  return x) & 0xff00u) >> 24) | (((x) & 0x00ffu) >> 8)
-  | (((x) & 0xff00u) << 8) | (((x) & 0x00ffu) << 24));
+  return (  (x & 0xff00) >> 24
+  | (x & 0x00ff) >>  8
+  | (x & 0xff00) <<  8
+  | (x & 0x00ff) << 24);
 #endif
 }
 
+#ifdef UINT_LEAST64_MAX
 /* Given an unsigned 64-bit argument X, return the value corresponding to
X with reversed byte order.  */
-_GL_BYTESWAP_INLINE uint64_t
-bswap_64 (uint64_t x)
+_GL_BYTESWAP_INLINE uint_least64_t
+bswap_64 (uint_least64_t x)
 {
-#ifdef _GL_BYTESWAP_HAS_BUILTIN_BSWAP64
+# ifdef _GL_BYTESWAP_HAS_BUILTIN_BSWAP64
   return __builtin_bswap64 (x);
-#else
-  return x) & 0xff00ull) >> 56)
-  | (((x) & 0x00ffull) >> 40)
-  | (((x) & 0xff00ull) >> 24)
-  | (((x) & 0x00ffull) >> 8)
-  | (((x) & 0xff00ull) << 8)
-  | (((x) & 0x00ffull) << 24)
-  | (((x) & 0xff00ull) << 40)
-  | (((x) & 0x00ffull) << 56));
-#endif
+# else
+  return (  (x & 0xff00) >> 56
+  | (x & 0x00ff) >> 40
+  | (x & 0xff00) >> 24
+  | (x & 0x00ff) >>  8
+  | (x & 0xff00) <<  8
+  | (x & 0x0

Re: byteswap: Use inline functions instead of macros.

2024-05-17 Thread Paul Eggert

On 2024-05-16 23:25, Collin Funk wrote:

Hi Paul,

On 5/16/24 10:16 PM, Paul Eggert wrote:

+#if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 3))\
+ || (defined __has_builtin && __has_builtin (__builtin_bswap32))


Unfortunately this usage is not portable, not for __has_builtin or for any of the other __has_XX primitives. This 
is because older compilers will replace "defined __has_builtin && __has_builtin 
(__builtin_bswap32)" with "1 && 0 (__builtin_bswap32)" and then complain about the bad 
syntax.


Oops, I wasn't aware of this. Was that a bug in old versions?


No, it was expected behavior before __has_builtin was standardized, the 
same behavior you'd get now with "#if defined FOO && FOO (x)" when FOO 
is not defined.





Re: [PATCH 1/2] alloca-opt-tests: add a ‘volatile’

2024-05-17 Thread Paul Eggert

On 2024-05-17 02:48, Bruno Haible wrote:

-flto was buggy for a long time. Is whole-program optimization working
fine for you? If so, which compiler version, binutils version, and
compiler options can you recommend?


No, I merely found that problem by program inspection. Like you, I've 
had problems with -flto.


The longer story is that my coreutils build was using GCC 14's new 
-Wmissing-variable-declarations behavior, which is a mistake for tests. 
While noticing the mistake I looked briefly at the complaints. This was 
an early test that -Wmissing-variable-declarations complained about and 
when I looked at the complaint I happened to notice the potential 
problem with whole-program optimization, something that has nothing to 
do with -Wmissing-variable-declarations.


In my weaker moments I sometimes think we should declare every test-case 
variable volatile, along the lines of the "volatile-by-default" approach 
for Java. See:


Liu L, Millstein T, Musuvathi M. Safe-by-default concurrency for modern 
programming languages. ACM TOPLAS. 2021;43(3):10. 
https://doi.org/10.1145/3462206




[PATCH 1/2] alloca-opt-tests: add a ‘volatile’

2024-05-16 Thread Paul Eggert
* tests/test-alloca-opt.c (func) [HAVE_ALLOCA]:
Now volatile, to foil whole-program optimization.
---
 ChangeLog   | 6 ++
 tests/test-alloca-opt.c | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index 6436ddfb81..a8ed30c4ae 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2024-05-16  Paul Eggert  
+
+   alloca-opt-tests: add a ‘volatile’
+   * tests/test-alloca-opt.c (func) [HAVE_ALLOCA]:
+   Now volatile, to foil whole-program optimization.
+
 2024-05-16  Collin Funk  
 
byteswap tests: Strengthen tests.
diff --git a/tests/test-alloca-opt.c b/tests/test-alloca-opt.c
index 3f20779c9e..b22921758e 100644
--- a/tests/test-alloca-opt.c
+++ b/tests/test-alloca-opt.c
@@ -29,7 +29,7 @@ do_allocation (int n)
   (void) ptr;
 }
 
-void (*func) (int) = do_allocation;
+void (*volatile func) (int) = do_allocation;
 
 #endif
 
-- 
2.45.0




[PATCH 2/2] putenv-tests: pacify gcc -Wdiscarded-qualifiers

2024-05-16 Thread Paul Eggert
* tests/test-putenv.c (main): Don’t pass a string literal
to a function expecting ‘char *’.
---
 ChangeLog   | 4 
 tests/test-putenv.c | 6 +++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index a8ed30c4ae..5238067cf9 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
 2024-05-16  Paul Eggert  
 
+   putenv-tests: pacify gcc -Wdiscarded-qualifiers
+   * tests/test-putenv.c (main): Don’t pass a string literal
+   to a function expecting ‘char *’.
+
alloca-opt-tests: add a ‘volatile’
* tests/test-alloca-opt.c (func) [HAVE_ALLOCA]:
Now volatile, to foil whole-program optimization.
diff --git a/tests/test-putenv.c b/tests/test-putenv.c
index 1768e7563a..564c86713a 100644
--- a/tests/test-putenv.c
+++ b/tests/test-putenv.c
@@ -39,7 +39,7 @@ main (void)
 
   /* Verify adding an environment variable.  */
   {
-ASSERT (putenv ("TEST_VAR=abc") == 0);
+ASSERT (putenv ((char []) {"TEST_VAR=abc"}) == 0);
 ptr = getenv ("TEST_VAR");
 ASSERT (ptr != NULL);
 ASSERT (STREQ (ptr, "abc"));
@@ -47,13 +47,13 @@ main (void)
 
   /* Verify removing an environment variable.  */
   {
-ASSERT (putenv ("TEST_VAR") == 0);
+ASSERT (putenv ((char []) {"TEST_VAR"}) == 0);
 ASSERT (getenv ("TEST_VAR") == NULL);
   }
 
   /* Verify the behavior when removing a variable not in the environment.  */
   {
-ASSERT (putenv ("TEST_VAR") == 0);
+ASSERT (putenv ((char []) {"TEST_VAR"}) == 0);
 ASSERT (getenv ("TEST_VAR") == NULL);
   }
 
-- 
2.45.0




Re: byteswap: Use inline functions instead of macros.

2024-05-16 Thread Paul Eggert

+#if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 3))\
+ || (defined __has_builtin && __has_builtin (__builtin_bswap32))


Unfortunately this usage is not portable, not for __has_builtin or for 
any of the other __has_XX primitives. This is because older compilers 
will replace "defined __has_builtin && __has_builtin 
(__builtin_bswap32)" with "1 && 0 (__builtin_bswap32)" and then complain 
about the bad syntax.


You can safely use __has_builtin (X) only inside a block that is 
protected by checking that __has_builtin is defined. See stdbit.in.h for 
an example.




[PATCH 1/2] stdbit: tweak for non-GCC non-Clang

2024-05-15 Thread Paul Eggert
* lib/stdbit.in.h (__gl_stdbit_clz, __gl_stdbit_clzl)
(__gl_stdbit_clzll, __gl_stdbit_ctz, __gl_stdbit_ctzl)
(__gl_stdbit_ctzll): Work even if the argument is zero.
All callers changed.  This should help avoid branches
on non-GCC-like platforms.
---
 ChangeLog   |  9 ++
 lib/stdbit.in.h | 73 +++--
 2 files changed, 56 insertions(+), 26 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index af8fb1e409..f37d9f2796 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2024-05-15  Paul Eggert  
+
+   stdbit: tweak for non-GCC non-Clang
+   * lib/stdbit.in.h (__gl_stdbit_clz, __gl_stdbit_clzl)
+   (__gl_stdbit_clzll, __gl_stdbit_ctz, __gl_stdbit_ctzl)
+   (__gl_stdbit_ctzll): Work even if the argument is zero.
+   All callers changed.  This should help avoid branches
+   on non-GCC-like platforms.
+
 2024-05-15  Bruno Haible  
 
vasnprintf: Avoid a dummy memory allocation.
diff --git a/lib/stdbit.in.h b/lib/stdbit.in.h
index 18efaf2d7c..984ef44ef9 100644
--- a/lib/stdbit.in.h
+++ b/lib/stdbit.in.h
@@ -85,11 +85,23 @@ extern "C" {
 # endif
 #endif
 
-/* Count leading zeros of nonzero N.  */
+/* Count leading 0 bits of N, even if N is 0.  */
 #ifdef _GL_STDBIT_HAS_BUILTIN_CLZ
-# define __gl_stdbit_clz __builtin_clz
-# define __gl_stdbit_clzl __builtin_clzl
-# define __gl_stdbit_clzll __builtin_clzll
+_GL_STDBIT_INLINE int
+__gl_stdbit_clz (unsigned int n)
+{
+  return n ? __builtin_clz (n) : 8 * sizeof n;
+}
+_GL_STDBIT_INLINE int
+__gl_stdbit_clzl (unsigned long int n)
+{
+  return n ? __builtin_clzl (n) : 8 * sizeof n;
+}
+_GL_STDBIT_INLINE int
+__gl_stdbit_clzll (unsigned long long int n)
+{
+  return n ? __builtin_clzll (n) : 8 * sizeof n;
+}
 #elif defined _MSC_VER
 # pragma intrinsic (_BitScanReverse)
 # ifdef _M_X64
@@ -99,8 +111,7 @@ _GL_STDBIT_INLINE int
 __gl_stdbit_clzl (unsigned long int n)
 {
   unsigned long int r;
-  _BitScanReverse (, n);
-  return 8 * sizeof n - 1 - r;
+  return 8 * sizeof n - (_BitScanReverse (, n) ? r + 1 : 0);
 }
 _GL_STDBIT_INLINE int
 __gl_stdbit_clz (unsigned int n)
@@ -112,8 +123,7 @@ __gl_stdbit_clzll (unsigned long long int n)
 {
 # ifdef _M_X64
   unsigned long int r;
-  _BitScanReverse64 (, n);
-  return 64 - 1 - r;
+  return 8 * sizeof n - (_BitScanReverse (, n) ? r + 1 : 0);
 # else
   unsigned long int hi = n >> 32;
   return __gl_stdbit_clzl (hi ? hi : n) + (hi ? 0 : 32);
@@ -148,10 +158,23 @@ __gl_stdbit_clzl (unsigned long int n)
 }
 #endif
 
+/* Count trailing 0 bits of N, even if N is 0.  */
 #ifdef _GL_STDBIT_HAS_BUILTIN_CTZ
-# define __gl_stdbit_ctz __builtin_ctz
-# define __gl_stdbit_ctzl __builtin_ctzl
-# define __gl_stdbit_ctzll __builtin_ctzll
+_GL_STDBIT_INLINE int
+__gl_stdbit_ctz (unsigned int n)
+{
+  return n ? __builtin_ctz (n) : 8 * sizeof n;
+}
+_GL_STDBIT_INLINE int
+__gl_stdbit_ctzl (unsigned long int n)
+{
+  return n ? __builtin_ctzl (n) : 8 * sizeof n;
+}
+_GL_STDBIT_INLINE int
+__gl_stdbit_ctzll (unsigned long long int n)
+{
+  return n ? __builtin_ctzll (n) : 8 * sizeof n;
+}
 #elif defined _MSC_VER
 # pragma intrinsic (_BitScanForward)
 # ifdef _M_X64
@@ -161,21 +184,19 @@ _GL_STDBIT_INLINE int
 __gl_stdbit_ctzl (unsigned long int n)
 {
   unsigned long int r;
-  _BitScanForward (, n);
-  return r;
+  return _BitScanForward (, n) ? r : 8 * sizeof n;
 }
 _GL_STDBIT_INLINE int
 __gl_stdbit_ctz (unsigned int n)
 {
-  return __gl_stdbit_ctzl (n);
+  return __gl_stdbit_ctzl (n | (1ul << (8 * sizeof n - 1) << 1));
 }
 _GL_STDBIT_INLINE int
 __gl_stdbit_ctzll (unsigned long long int n)
 {
 # ifdef _M_X64
   unsigned long int r;
-  _BitScanForward64 (, n);
-  return r;
+  return _BitScanForward64 (, n) ? r : 8 * sizeof n;
 # else
   unsigned int lo = n;
   return __gl_stdbit_ctzl (lo ? lo : n >> 32) + (lo ? 0 : 32);
@@ -188,26 +209,26 @@ _GL_STDBIT_INLINE int
 _GL_STDBIT_INLINE int
 __gl_stdbit_ctz (unsigned int n)
 {
-  return 8 * sizeof n - 1 - __gl_stdbit_clz (n & -n);
+  return 8 * sizeof n - (n ? __gl_stdbit_clz (n & -n) + 1 : 0);
 }
 _GL_STDBIT_INLINE int
 __gl_stdbit_ctzl (unsigned long int n)
 {
-  return 8 * sizeof n - 1 - __gl_stdbit_clzl (n & -n);
+  return 8 * sizeof n - (n ? __gl_stdbit_clzl (n & -n) + 1 : 0);
 }
 _GL_STDBIT_INLINE int
 __gl_stdbit_ctzll (unsigned long long int n)
 {
-  return 8 * sizeof n - 1 - __gl_stdbit_clzll (n & -n);
+  return 8 * sizeof n - (n ? __gl_stdbit_clzll (n & -n) + 1 : 0);
 }
 #endif
 
+/* Count 1 bits in N.  */
 #ifdef _GL_STDBIT_HAS_BUILTIN_POPCOUNT
 # define __gl_stdbit_popcount __builtin_popcount
 # define __gl_stdbit_popcountl __builtin_popcountl
 # define __gl_stdbit_popcountll __builtin_popcountll
 #else
-/* Count the number of 1 bits in N.  */
 _GL_STDBIT_INLINE int
 __gl_stdbit_popcount_wide (unsigned long long int n)
 {
@@ -320,7 +341,7 @@ __gl_stdbit_popcountll (unsigned long long int n)
 _GL_STDBIT_INLINE unsigned int
 stdc_leading_zeros_ui

[PATCH 2/2] stdbit: tweak first_leading for GCC

2024-05-15 Thread Paul Eggert
* lib/stdbit.in.h (stdc_first_leading_zero)
(stdc_first_leading_one, stdc_first_trailing_zero_uc)
(stdc_first_trailing_one_uc): Redo to avoid the need for a
conditional branch, at least on x86-64 with GCC 14.
---
 ChangeLog   |  7 +-
 lib/stdbit.in.h | 60 -
 2 files changed, 46 insertions(+), 21 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index f37d9f2796..049f27b3b8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,6 +1,11 @@
 2024-05-15  Paul Eggert  
 
-   stdbit: tweak for non-GCC non-Clang
+   stdbit: tweak first_leading for GCC
+   * lib/stdbit.in.h (stdc_first_leading_zero)
+   (stdc_first_leading_one, stdc_first_trailing_zero_uc)
+   (stdc_first_trailing_one_uc): Redo to avoid the need for a
+   conditional branch, at least on x86-64 with GCC 14.
+
* lib/stdbit.in.h (__gl_stdbit_clz, __gl_stdbit_clzl)
(__gl_stdbit_clzll, __gl_stdbit_ctz, __gl_stdbit_ctzl)
(__gl_stdbit_ctzll): Work even if the argument is zero.
diff --git a/lib/stdbit.in.h b/lib/stdbit.in.h
index 984ef44ef9..ab328a7793 100644
--- a/lib/stdbit.in.h
+++ b/lib/stdbit.in.h
@@ -494,35 +494,40 @@ _GL_STDBIT_INLINE unsigned int
 stdc_first_leading_zero_uc (unsigned char n)
 {
   unsigned int count = stdc_leading_ones_uc (n);
-  return count == 8 * sizeof n ? 0 : count + 1;
+  unsigned int bits = 8 * sizeof n;
+  return count % bits + (count < bits);
 }
 
 _GL_STDBIT_INLINE unsigned int
 stdc_first_leading_zero_us (unsigned short int n)
 {
   unsigned int count = stdc_leading_ones_us (n);
-  return count == 8 * sizeof n ? 0 : count + 1;
+  unsigned int bits = 8 * sizeof n;
+  return count % bits + (count < bits);
 }
 
 _GL_STDBIT_INLINE unsigned int
 stdc_first_leading_zero_ui (unsigned int n)
 {
   unsigned int count = stdc_leading_ones_ui (n);
-  return count == 8 * sizeof n ? 0 : count + 1;
+  unsigned int bits = 8 * sizeof n;
+  return count % bits + (count < bits);
 }
 
 _GL_STDBIT_INLINE unsigned int
 stdc_first_leading_zero_ul (unsigned long int n)
 {
   unsigned int count = stdc_leading_ones_ul (n);
-  return count == 8 * sizeof n ? 0 : count + 1;
+  unsigned int bits = 8 * sizeof n;
+  return count % bits + (count < bits);
 }
 
 _GL_STDBIT_INLINE unsigned int
 stdc_first_leading_zero_ull (unsigned long long int n)
 {
   unsigned int count = stdc_leading_ones_ull (n);
-  return count == 8 * sizeof n ? 0 : count + 1;
+  unsigned int bits = 8 * sizeof n;
+  return count % bits + (count < bits);
 }
 
 #define stdc_first_leading_zero(n) \
@@ -537,35 +542,40 @@ _GL_STDBIT_INLINE unsigned int
 stdc_first_leading_one_uc (unsigned char n)
 {
   unsigned int count = stdc_leading_zeros_uc (n);
-  return count == 8 * sizeof n ? 0 : count + 1;
+  unsigned int bits = 8 * sizeof n;
+  return count % bits + (count < bits);
 }
 
 _GL_STDBIT_INLINE unsigned int
 stdc_first_leading_one_us (unsigned short int n)
 {
   unsigned int count = stdc_leading_zeros_us (n);
-  return count == 8 * sizeof n ? 0 : count + 1;
+  unsigned int bits = 8 * sizeof n;
+  return count % bits + (count < bits);
 }
 
 _GL_STDBIT_INLINE unsigned int
 stdc_first_leading_one_ui (unsigned int n)
 {
   unsigned int count = stdc_leading_zeros_ui (n);
-  return count == 8 * sizeof n ? 0 : count + 1;
+  unsigned int bits = 8 * sizeof n;
+  return count % bits + (count < bits);
 }
 
 _GL_STDBIT_INLINE unsigned int
 stdc_first_leading_one_ul (unsigned long int n)
 {
   unsigned int count = stdc_leading_zeros_ul (n);
-  return count == 8 * sizeof n ? 0 : count + 1;
+  unsigned int bits = 8 * sizeof n;
+  return count % bits + (count < bits);
 }
 
 _GL_STDBIT_INLINE unsigned int
 stdc_first_leading_one_ull (unsigned long long int n)
 {
   unsigned int count = stdc_leading_zeros_ull (n);
-  return count == 8 * sizeof n ? 0 : count + 1;
+  unsigned int bits = 8 * sizeof n;
+  return count % bits + (count < bits);
 }
 
 #define stdc_first_leading_one(n) \
@@ -580,35 +590,40 @@ _GL_STDBIT_INLINE unsigned int
 stdc_first_trailing_zero_uc (unsigned char n)
 {
   unsigned int count = stdc_trailing_ones_uc (n);
-  return count == 8 * sizeof n ? 0 : count + 1;
+  unsigned int bits = 8 * sizeof n;
+  return count % bits + (count < bits);
 }
 
 _GL_STDBIT_INLINE unsigned int
 stdc_first_trailing_zero_us (unsigned short int n)
 {
   unsigned int count = stdc_trailing_ones_us (n);
-  return count == 8 * sizeof n ? 0 : count + 1;
+  unsigned int bits = 8 * sizeof n;
+  return count % bits + (count < bits);
 }
 
 _GL_STDBIT_INLINE unsigned int
 stdc_first_trailing_zero_ui (unsigned int n)
 {
   unsigned int count = stdc_trailing_ones_ui (n);
-  return count == 8 * sizeof n ? 0 : count + 1;
+  unsigned int bits = 8 * sizeof n;
+  return count % bits + (count < bits);
 }
 
 _GL_STDBIT_INLINE unsigned int
 stdc_first_trailing_zero_ul (unsigned long int n)
 {
   unsigned int count = stdc_trailing_ones_ul (n);
-  return count == 8 * sizeof n ? 0 : count +

Re: endian: New module.

2024-05-15 Thread Paul Eggert

On 2024-05-13 15:34, Collin Funk wrote:

To fix this, please use _GL_INLINE and implement with inline functions. And add 
please add test cases to catch these issues.

If we can ensure byteswap.h functions are defined as functions,
wouldn't it make sense to just define these as macros to them?


Not sure why macros would be helpful. If functions suffice for good 
performance when compiling with -O2, it's better to use functions than 
macros.





Re: Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists

2024-05-14 Thread Paul Eggert

On 2024-05-14 02:24, Bruno Haible wrote:

I can do the same in gnulib-tool.sh
if you would like since it should be pretty easy there too.

This is not needed. The Python implementation is already the default.
We haven't heard from anyone who needs to run the shell implementation.


I still need to run it.

I am still falling back on the shell implementation when I discover 
gnulib-tool.py bugs or issues, and that's still happening to me (as 
recently as yesterday). So Collin, if it's not too much trouble, please 
update gnulib-tool.sh for this mkdir issue. (I'll do it if you don't 
have the time.) Thanks.





Re: [PATCH 3/4] stdbit: remove most module dependence

2024-05-14 Thread Paul Eggert

On 2024-05-13 14:08, Collin Funk wrote:

Shouldn't 'Depends-on' contain extern-inline?


Thanks, I fixed that.



Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists

2024-05-13 Thread Paul Eggert

If I run this command twice, by mistake:

./gnulib-tool --create-testdir --dir foo -h stdbit
./gnulib-tool --create-testdir --dir foo -h stdbit

The second invocation eventually fails with:

  ...
  executing automake --add-missing --copy
  patching file build-aux/test-driver
  /home/eggert/src/gnu/gnulib/gnulib-tool.py: *** could not patch 
test-driver script

  /home/eggert/src/gnu/gnulib/gnulib-tool.py: *** Stop.

I messed up. However, the shell implementation of gnulib-tool diagnoses 
my mistake right away, before going on its slow way:


  $ GNULIB_TOOL_IMPL=sh ./gnulib-tool --create-testdir --dir foo -h stdbit
  mkdir: cannot create directory ‘foo’: File exists
  Module list with included dependencies (indented):
  absolute-header
  alignasof

and it'd be nice if the Python implementation was as fast as the shell 
implementation in this case.


Perhaps both implementations should quickly exit in this situation, come 
to think of it.




Re: *.m4 conventions

2024-05-13 Thread Paul Eggert

On 2024-05-13 13:23, Bruno Haible wrote:

   # stdio_h.m4 - Autoconf macros for the stdio module.
   # serial 42


Oh, I didn't know you could do that. Thanks, I'll keep it in mind.



Re: considering L1 cache

2024-05-13 Thread Paul Eggert

On 5/13/24 09:17, Bruno Haible wrote:

The reason is that such a 256-bytes table will tend to occupy 256 bytes in the
CPU's L1 cache, and thus reduce the ability of other code to use the L1 cache.


Yes, it partly depends on whether the function is called a lot (so the 
256-byte table is in the cache) or rarely (so it's not). I had optimized 
for the former.


The code can be changed to not use an extern data table. I installed the 
attached. This probably a win (over de Bruijn too), at least for some 
apps and platforms, though I haven't benchmarked.From 1b7e82be9dd80fbb67a5567cdf1d60d36dd40db2 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 13 May 2024 15:21:55 -0700
Subject: [PATCH] stdbit: redo clzll without lookcup table

* lib/stdbit.c (__gl_stdbit_clztab):
* lib/stdbit.in.h (__gl_stdbit_clzll):
[!_GL_STDBIT_HAS_BUILTIN_CLZ && !_MSC_VER]: Rewrite to avoid the
need for a lookup table in memory, and remove the lookup table.
Do this by shrinking the table to 64 bits and puttiung in a 64-bit
constant.  Although this needs another round of shifts, it avoids
the need for a multiplication and memory access a la de Bruijn,
and is probably a win.
---
 ChangeLog   | 12 
 lib/stdbit.c| 24 
 lib/stdbit.in.h |  5 ++---
 3 files changed, 14 insertions(+), 27 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 18aab772fc..3e4eba3796 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2024-05-13  Paul Eggert  
+
+	stdbit: redo clzll without lookcup table
+	* lib/stdbit.c (__gl_stdbit_clztab):
+	* lib/stdbit.in.h (__gl_stdbit_clzll):
+	[!_GL_STDBIT_HAS_BUILTIN_CLZ && !_MSC_VER]: Rewrite to avoid the
+	need for a lookup table in memory, and remove the lookup table.
+	Do this by shrinking the table to 64 bits and puttiung in a 64-bit
+	constant.  Although this needs another round of shifts, it avoids
+	the need for a multiplication and memory access a la de Bruijn,
+	and is probably a win.
+
 2024-05-13  Bruno Haible  
 
 	stdbit tests: Adhere better to Gnulib naming conventions.
diff --git a/lib/stdbit.c b/lib/stdbit.c
index f2a51b10f7..a9f0ef5074 100644
--- a/lib/stdbit.c
+++ b/lib/stdbit.c
@@ -22,30 +22,6 @@
 #define _GL_STDBIT_INLINE _GL_EXTERN_INLINE
 #include 
 
-#if !defined _GL_STDBIT_HAS_BUILTIN_CLZ && !_MSC_VER
-/* __gl_stdbit_clztab[B] is the number of leading zeros in
-   the 8-bit byte with value B.  */
-char const __gl_stdbit_clztab[256] =
-  {
-8,
-7,
-6, 6,
-5, 5, 5, 5,
-4, 4, 4, 4, 4, 4, 4, 4,
-3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
-
-2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
-2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
-
-1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
-1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
-1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
-1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
-
-/* The rest is zero.  */
-  };
-#endif
-
 #if 1500 <= _MSC_VER && (defined _M_IX86 || defined _M_X64)
 signed char __gl_stdbit_popcount_support;
 #endif
diff --git a/lib/stdbit.in.h b/lib/stdbit.in.h
index 15533dbbda..18efaf2d7c 100644
--- a/lib/stdbit.in.h
+++ b/lib/stdbit.in.h
@@ -122,8 +122,6 @@ __gl_stdbit_clzll (unsigned long long int n)
 
 #else /* !_MSC_VER */
 
-extern char const __gl_stdbit_clztab[256];
-
 _GL_STDBIT_INLINE int
 __gl_stdbit_clzll (unsigned long long int n)
 {
@@ -135,7 +133,8 @@ __gl_stdbit_clzll (unsigned long long int n)
   int a5 = (0x < n) << 5; n >>= a5; r += a5;
   int a4 = (0x < n) << 4; n >>= a4; r += a4;
   int a3 = (0x00ff < n) << 3; n >>= a3; r += a3;
-  return (8 * (sizeof n - 1) - r) + __gl_stdbit_clztab[n];
+  int a2 = (0x000f < n) << 2; n >>= a2; r += a2;
+  return (8 * sizeof n - (1 << 2) - r) + ((0x2234ull >> (n << 2)) & 0xf);
 }
 _GL_STDBIT_INLINE int
 __gl_stdbit_clz (unsigned int n)
-- 
2.45.0



Re: *.m4 conventions

2024-05-13 Thread Paul Eggert

On 2024-05-13 09:57, Bruno Haible wrote:

Note that in Gnulib, a human-readable comment
   # Autoconf macros for the stdio module.
is just as trivial as this comment:
   # stdio_h.m4


Although that's true for experts, it's not necessarily true for 
beginners who are the main audience for the first line. A beginner won't 
know whether stdio_h.m4 is for the entire stdio module, or just for 
configuring the stdio.h replacement, or just for configuring the stdio 
implementation, or something else.


In general the first line could be quite helpful for a brief explanation 
of file contents, for non experts. Yes, this information can be put 
elsewhere in the .m4 file, but the first line is a better place for it.




Re: [PATCH 2/4] stdbit-tests: new module

2024-05-13 Thread Paul Eggert

On 2024-05-13 10:47, Bruno Haible wrote:


I would propose to rename the files to 'test-*' in Gnulib. They are
not likely to be modified frequently in glibc, therefore the gnulib <--> glibc
merge effort is likely zero. And annotate the mapping in config/srclist.txt
accordingly.


Wouldn't we also need to change config/srclist-update to support file 
renaming? And even then it'd be confusing for the files to have 
different basenames in gnulib vs glibc.




If you have objections to that, I would instead
   - move the tst-* files to a subdirectory, say from-glibc/,
   - change the module descriptions so that
   tests/from-glibc/tst-stdc_trailing_zeros.c
 is compiled to an executable named
   ${tests_prefix}/test-stdc_trailing_zeros${EXEEXT}.
So that the autocompletion again works.


That should work, and I think it wouldn't need changes to 
config/srclist-update. Thanks.




Re: why __gl_ prefix?

2024-05-13 Thread Paul Eggert

On 2024-05-13 10:33, Bruno Haible wrote:

In the stdbit and binary-io modules, you have been introducing a number
of a symbols with prefix __gl_.

I would propose to remove the first underscore, that is, to rename them
to_gl_*.

Rationale:
* It is well understood that symbols prefixed with __ belong
   to the implementation of the system, that is, to the compiler and libc.
   Gnulib code is application code, from this perspective.
* I've seen gcc 14 warnings for '#undef __STDC_VERSION_STDDEF_H__' [1]
   and I don't know how the compilers will evolve in their handling of
   such symbols.


I take your point, but when Gnulib implements a standard C or POSIX 
feature the Gnulib code is arguably part of the implementation not the 
application.


For stdbit.h the issue was whether stdbit.h should be namespace clean as 
required by the standards, or whether it should avoid using identifiers 
reserved to the implementation. I saw no practical way to do both, and 
chose the former.


Gnulib defines many other "belong to the implementation" symbols such as 
__gl_error_call and _GL_EXTERN. Many of these symbols are inherited from 
Gnulib's copying of glibc code, e.g., __glibc_likely. So I figured there 
was a lot of precedent for this sort of thing.




Re: endian: New module.

2024-05-13 Thread Paul Eggert
Unfortunately this patch suffers from the problem we discussed earlier, 
e.g., the substitute be16toh (n++) has undefined behavior but it should 
add 1 to n and otherwise act as if be16toh (n) was called.


Also, the returned values and types are sometimes wrong. E.g., on x86-64 
be16toh (-1) should return 0x of type uint16_t, but it returns -1 of 
type int.


These problems arise because Gnulib byteswap.h's macros can evaluate 
their arguments more than once, and are type-generic in a way that is 
incompatible with what POSIX wants for endian.h functions.


Also, there's a bizarre compatibility issue, in that some floating-point 
args have well-defined behavior in the POSIX spec, e.g., be16toh (0.0) 
yields 0, but this implementation rejects these calls. Although this is 
lower priority it's easy to fix so we might as well do it.


To fix this, please use _GL_INLINE and implement with inline functions. 
And add please add test cases to catch these issues.




[PATCH] stdbit: fix typo in MS-Windows port

2024-05-13 Thread Paul Eggert
Problem reported by Mattias Engdegård <https://bugs.gnu.org/70898#8>.
* lib/stdbit.in.h (__gl_stdbit_popcount_support) [_MSC_VER]:
Fix misspelling in decl.
---
 ChangeLog   | 7 +++
 lib/stdbit.in.h | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index 0f9be38ca8..97d3ab8813 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2024-05-13  Paul Eggert  
+
+   stdbit: fix typo in MS-Windows port
+   Problem reported by Mattias Engdegård <https://bugs.gnu.org/70898#8>.
+   * lib/stdbit.in.h (__gl_stdbit_popcount_support) [_MSC_VER]:
+   Fix misspelling in decl.
+
 2024-05-13  Bruno Haible  
 
doc: Document  function-like macros.
diff --git a/lib/stdbit.in.h b/lib/stdbit.in.h
index 36349af1fd..15533dbbda 100644
--- a/lib/stdbit.in.h
+++ b/lib/stdbit.in.h
@@ -272,7 +272,7 @@ __popcnt64 (unsigned long long int n)
 #  endif
 
 /* 1 if supported, -1 if not, 0 if unknown.  */
-extern signed char __gl_stdint_popcount_support;
+extern signed char __gl_stdbit_popcount_support;
 
 _GL_STDBIT_INLINE bool
 __gl_stdbit_popcount_supported (void)
-- 
2.40.1




gnulib-tool Python tracebacks after control-C

2024-05-13 Thread Paul Eggert
I realized that I invoked ' ./gnulib-tool --create-testdir --dir foo 
stdbit' with the wrong options so I interrupted it with control-C. It 
then gave me the following long traceback, which is not useful. I 
suggest shutting off the Python traceback info after control-C unless 
perhaps some new debugging option is used.


...
executing touch config.h.in
executing automake --add-missing --copy
  C-c C-cTraceback (most recent call last):
  File "/home/eggert/src/gnu/gnulib/./.gnulib-tool.py", line 30, in 


main.main_with_exception_handling()
  File "/home/eggert/src/gnu/gnulib/pygnulib/main.py", line 1371, in 
main_with_exception_handling

main(temporary_directory)
  File "/home/eggert/src/gnu/gnulib/pygnulib/main.py", line 1073, in main
testdir.execute()
  File "/home/eggert/src/gnu/gnulib/pygnulib/GLTestDir.py", line 707, 
in execute

execute(args, verbose)
  File "/home/eggert/src/gnu/gnulib/pygnulib/constants.py", line 210, 
in execute

retcode = sp.call(args)
  ^
  File "/usr/lib/python3.11/subprocess.py", line 391, in call
return p.wait(timeout=timeout)
   ^^^
  File "/usr/lib/python3.11/subprocess.py", line 1264, in wait
return self._wait(timeout=timeout)
   ^^^
  File "/usr/lib/python3.11/subprocess.py", line 2046, in _wait
(pid, sts) = self._try_wait(0)
 ^
  File "/usr/lib/python3.11/subprocess.py", line 2004, in _try_wait
(pid, sts) = os.waitpid(self.pid, wait_flags)
 
KeyboardInterrupt



Re: doc: Document function-like macros

2024-05-13 Thread Paul Eggert
Thanks for doing that. A later free draft of C23 is available, so I 
installed the attached. I think the section numbers are the same (though 
I didn't check this).From 623b86c05be45e5e567b828cd71d1b78c52012db Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 13 May 2024 09:29:00 -0700
Subject: [PATCH] doc: update C23 draft ref from n3047 to n3096

---
 doc/glibc-functions/timespec_get.texi | 2 +-
 doc/posix-functions/stdc_bit_ceil.texi| 2 +-
 doc/posix-functions/stdc_bit_floor.texi   | 2 +-
 doc/posix-functions/stdc_bit_width.texi   | 2 +-
 doc/posix-functions/stdc_count_ones.texi  | 2 +-
 doc/posix-functions/stdc_count_zeros.texi | 2 +-
 doc/posix-functions/stdc_first_leading_one.texi   | 2 +-
 doc/posix-functions/stdc_first_leading_zero.texi  | 2 +-
 doc/posix-functions/stdc_first_trailing_one.texi  | 2 +-
 doc/posix-functions/stdc_first_trailing_zero.texi | 2 +-
 doc/posix-functions/stdc_has_single_bit.texi  | 2 +-
 doc/posix-functions/stdc_leading_ones.texi| 2 +-
 doc/posix-functions/stdc_leading_zeros.texi   | 2 +-
 doc/posix-functions/stdc_trailing_ones.texi   | 2 +-
 doc/posix-functions/stdc_trailing_zeros.texi  | 2 +-
 doc/posix-functions/timespec_getres.texi  | 2 +-
 doc/posix-headers/stdalign.texi   | 2 +-
 doc/posix-headers/stdbit.texi | 2 +-
 doc/posix-headers/stdckdint.texi  | 2 +-
 m4/stdalign.m4| 2 +-
 20 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/doc/glibc-functions/timespec_get.texi b/doc/glibc-functions/timespec_get.texi
index a1f6512f50..ab3d87927f 100644
--- a/doc/glibc-functions/timespec_get.texi
+++ b/doc/glibc-functions/timespec_get.texi
@@ -2,7 +2,7 @@
 @subsection @code{timespec_get}
 @findex timespec_get
 
-ISO C23 specification:@* @url{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf} section 7.29.2.6
+ISO C23 specification:@* @url{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf} section 7.29.2.6
 
 Gnulib module: timespec_get
 
diff --git a/doc/posix-functions/stdc_bit_ceil.texi b/doc/posix-functions/stdc_bit_ceil.texi
index 7597c9fcea..5b636e6b02 100644
--- a/doc/posix-functions/stdc_bit_ceil.texi
+++ b/doc/posix-functions/stdc_bit_ceil.texi
@@ -4,7 +4,7 @@
 
 Documentation:@*
 ISO C23 (latest free draft
-@url{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf})
+@url{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf})
 section 7.18.16.
 
 Gnulib module: stdbit
diff --git a/doc/posix-functions/stdc_bit_floor.texi b/doc/posix-functions/stdc_bit_floor.texi
index cf2c2aad05..2600aa7b9a 100644
--- a/doc/posix-functions/stdc_bit_floor.texi
+++ b/doc/posix-functions/stdc_bit_floor.texi
@@ -4,7 +4,7 @@
 
 Documentation:@*
 ISO C23 (latest free draft
-@url{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf})
+@url{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf})
 section 7.18.15.
 
 Gnulib module: stdbit
diff --git a/doc/posix-functions/stdc_bit_width.texi b/doc/posix-functions/stdc_bit_width.texi
index 7e25c3f325..d0bcb359f0 100644
--- a/doc/posix-functions/stdc_bit_width.texi
+++ b/doc/posix-functions/stdc_bit_width.texi
@@ -4,7 +4,7 @@
 
 Documentation:@*
 ISO C23 (latest free draft
-@url{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf})
+@url{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf})
 section 7.18.14.
 
 Gnulib module: stdbit
diff --git a/doc/posix-functions/stdc_count_ones.texi b/doc/posix-functions/stdc_count_ones.texi
index 892a27dd47..17a0e520d8 100644
--- a/doc/posix-functions/stdc_count_ones.texi
+++ b/doc/posix-functions/stdc_count_ones.texi
@@ -4,7 +4,7 @@
 
 Documentation:@*
 ISO C23 (latest free draft
-@url{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf})
+@url{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf})
 section 7.18.12.
 
 Gnulib module: stdbit
diff --git a/doc/posix-functions/stdc_count_zeros.texi b/doc/posix-functions/stdc_count_zeros.texi
index c5717e823a..18867146e4 100644
--- a/doc/posix-functions/stdc_count_zeros.texi
+++ b/doc/posix-functions/stdc_count_zeros.texi
@@ -4,7 +4,7 @@
 
 Documentation:@*
 ISO C23 (latest free draft
-@url{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf})
+@url{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf})
 section 7.18.11.
 
 Gnulib module: stdbit
diff --git a/doc/posix-functions/stdc_first_leading_one.texi b/doc/posix-functions/stdc_first_leading_one.texi
index 103586df77..f82cb2f940 100644
--- a/doc/posix-functions/stdc_first_leading_one.texi
+++ b/doc/posix-functions/stdc_first_leading_one.texi
@@ -4,7 +4,7 @@
 
 Documentation:@*
 ISO C23 (latest free draft
-@url{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf})
+@url{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf})
 section 7.18.8.
 
 Gnulib module: stdbit
diff --git a/doc/posix-functions/stdc_first_leading_zero.texi b/doc/posix

[PATCH 1/2] stdbit-tests: make GNULIB_TEST_STDBIT work standalone

2024-05-13 Thread Paul Eggert
* modules/stdbit-tests (GNULIB_TEST_STDBIT):
Do not define in config.h, since config.h is conditionally
included depending on this macro.
Instead, specify -DGNULIB_TEST_STDBIT in the CPPFLAGS
of each test.
---
 ChangeLog|  9 +
 modules/stdbit-tests | 18 --
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b6aa21d7f7..e14eedd9c7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2024-05-12  Paul Eggert  
+
+   stdbit-tests: make GNULIB_TEST_STDBIT work standalone
+   * modules/stdbit-tests (GNULIB_TEST_STDBIT):
+   Do not define in config.h, since config.h is conditionally
+   included depending on this macro.
+   Instead, specify -DGNULIB_TEST_STDBIT in the CPPFLAGS
+   of each test.
+
 2024-05-12  Simon Josefsson  
 
maintainer-makefile: Silence announce-gen error with GNULIB_REVISION.
diff --git a/modules/stdbit-tests b/modules/stdbit-tests
index a5832c84f2..3361ff62e0 100644
--- a/modules/stdbit-tests
+++ b/modules/stdbit-tests
@@ -23,8 +23,6 @@ libc-config
 stdint
 
 configure.ac:
-AC_DEFINE([GNULIB_TEST_STDBIT], [1],
-  [Define to 1 so that stdbit tests use the Gnulib framework, not glibc's.])
 
 Makefile.am:
 TESTS += \
@@ -42,3 +40,19 @@ check_PROGRAMS += \
tst-stdc_first_trailing_zero tst-stdc_has_single_bit \
tst-stdc_leading_ones tst-stdc_leading_zeros tst-stdc_trailing_ones \
tst-stdc_trailing_zeros
+
+TEST_STDBIT_CPPFLAGS = $(AM_CPPFLAGS) -DGNULIB_TEST_STDBIT
+tst_stdc_bit_ceil_CPPFLAGS= $(TEST_STDBIT_CPPFLAGS)
+tst_stdc_bit_floor_CPPFLAGS   = $(TEST_STDBIT_CPPFLAGS)
+tst_stdc_bit_width_CPPFLAGS   = $(TEST_STDBIT_CPPFLAGS)
+tst_stdc_count_ones_CPPFLAGS  = $(TEST_STDBIT_CPPFLAGS)
+tst_stdc_count_zeros_CPPFLAGS = $(TEST_STDBIT_CPPFLAGS)
+tst_stdc_first_leading_one_CPPFLAGS   = $(TEST_STDBIT_CPPFLAGS)
+tst_stdc_first_leading_zero_CPPFLAGS  = $(TEST_STDBIT_CPPFLAGS)
+tst_stdc_first_trailing_one_CPPFLAGS  = $(TEST_STDBIT_CPPFLAGS)
+tst_stdc_first_trailing_zero_CPPFLAGS = $(TEST_STDBIT_CPPFLAGS)
+tst_stdc_has_single_bit_CPPFLAGS  = $(TEST_STDBIT_CPPFLAGS)
+tst_stdc_leading_ones_CPPFLAGS= $(TEST_STDBIT_CPPFLAGS)
+tst_stdc_leading_zeros_CPPFLAGS   = $(TEST_STDBIT_CPPFLAGS)
+tst_stdc_trailing_ones_CPPFLAGS   = $(TEST_STDBIT_CPPFLAGS)
+tst_stdc_trailing_zeros_CPPFLAGS  = $(TEST_STDBIT_CPPFLAGS)
-- 
2.40.1




[PATCH 2/2] stdbit: port to theoretical platforms

2024-05-13 Thread Paul Eggert
Port to theoretical platforms that C and POSIX allow but are not
likely to ever exist.  This is mostly just to document the existing
source code: when optimizing, the machine code should be largely
unchanged even on platforms lacking __builtin_clz etc.
* lib/stdbit.in.h: Omit static_assert that checks for 8-bit bits.
stdbit-tests checks for this, and omitting the static_assert here
removes a module dependency.
(__gl_stdbit_clzll): Do not limit word size to 128 bits.
(__gl_stdbit_popcount255): Rename from __gl_stdbit_popcount255.
All uses changed.  Do not limit word size to 255 bits.  Correct
bugs on odd theoretical platforms where the word size is not a
power of 2.
* modules/stdbit (Depends-on): Remove assert-h.
---
 ChangeLog   | 17 ++
 lib/stdbit.in.h | 88 -
 modules/stdbit  |  1 -
 3 files changed, 74 insertions(+), 32 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index e14eedd9c7..b1cc7ffcf0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,20 @@
+2024-05-13  Paul Eggert  
+
+   stdbit: port to theoretical platforms
+   Port to theoretical platforms that C and POSIX allow but are not
+   likely to ever exist.  This is mostly just to document the existing
+   source code: when optimizing, the machine code should be largely
+   unchanged even on platforms lacking __builtin_clz etc.
+   * lib/stdbit.in.h: Omit static_assert that checks for 8-bit bits.
+   stdbit-tests checks for this, and omitting the static_assert here
+   removes a module dependency.
+   (__gl_stdbit_clzll): Do not limit word size to 128 bits.
+   (__gl_stdbit_popcount255): Rename from __gl_stdbit_popcount255.
+   All uses changed.  Do not limit word size to 255 bits.  Correct
+   bugs on odd theoretical platforms where the word size is not a
+   power of 2.
+   * modules/stdbit (Depends-on): Remove assert-h.
+
 2024-05-12  Paul Eggert  
 
stdbit-tests: make GNULIB_TEST_STDBIT work standalone
diff --git a/lib/stdbit.in.h b/lib/stdbit.in.h
index ed68bd6513..36349af1fd 100644
--- a/lib/stdbit.in.h
+++ b/lib/stdbit.in.h
@@ -34,10 +34,6 @@ _GL_INLINE_HEADER_BEGIN
 extern "C" {
 #endif
 
-/* Bytes must be 8 bits, as POSIX requires.  This implementation uses
-   8 instead of CHAR_BIT to avoid namespace pollution.  */
-static_assert ((unsigned char) -1 == (1 << 8) - 1);
-
 /* An expression, preferably with the type of A, that has the value of B.  */
 #if ((defined __GNUC__ && 2 <= __GNUC__) \
  || (defined __clang_major__ && 4 <= __clang_major__) \
@@ -131,13 +127,15 @@ extern char const __gl_stdbit_clztab[256];
 _GL_STDBIT_INLINE int
 __gl_stdbit_clzll (unsigned long long int n)
 {
-  static_assert (8 * sizeof n <= 1 << 7);
   int r = 0;
-  int a6 = (0x < n) << 6; n >>= a6; r |= a6;
-  int a5 = (0x < n) << 5; n >>= a5; r |= a5;
-  int a4 = (0x < n) << 4; n >>= a4; r |= a4;
-  int a3 = (0x00ff < n) << 3; n >>= a3; r |= a3;
-  return (8 * (sizeof n - 1) - r) | __gl_stdbit_clztab[n];
+  for (int i = 8 * sizeof n >> 1; 1 << 6 <= i; i >>= 1)
+{
+  int a = (1ull << i <= n) * i; n >>= a; r += a;
+}
+  int a5 = (0x < n) << 5; n >>= a5; r += a5;
+  int a4 = (0x < n) << 4; n >>= a4; r += a4;
+  int a3 = (0x00ff < n) << 3; n >>= a3; r += a3;
+  return (8 * (sizeof n - 1) - r) + __gl_stdbit_clztab[n];
 }
 _GL_STDBIT_INLINE int
 __gl_stdbit_clz (unsigned int n)
@@ -212,22 +210,50 @@ __gl_stdbit_ctzll (unsigned long long int n)
 #else
 /* Count the number of 1 bits in N.  */
 _GL_STDBIT_INLINE int
-__gl_stdbit_popcount255 (unsigned long long int n)
+__gl_stdbit_popcount_wide (unsigned long long int n)
 {
-  unsigned long long int
-max = -1ull,
-x55 = max / (1 << 1 | 1),  /* 0x55... */
-x33 = max / (1 << 2 | 1),  /* 0x33... */
-x0f0f0f = max / (1 << 4 | 1),  /* 0x0f0f0f... */
-x010101 = max / ((1 << 8) - 1);/* 0x010101... */
-  n -= (n >> 1) & x55;
-  n = (n & x33) + ((n >> 2) & x33);
-  n = (n + (n >> 4)) & x0f0f0f;
-
-  /* The multiplication means the popcount should fit in the leading 8
- bits of the product, so N should be narrower than 256 bits.  */
-  static_assert (8 * sizeof n < 1 << 8);
-  return n * x010101 >> 8 * (sizeof n - 1);
+  if (sizeof n & (sizeof n - 1))
+{
+  /* Use a simple O(log N) loop on theoretical platforms where N's
+ width is not a power of 2.  */
+  int count = 0;
+  for (int i = 0; i < 8 * sizeof n; i++, n >>= 1)
+count += n & 1;
+  return count;
+}
+  else
+{
+  /* N's width is a power of 2; coun

Re: [PATCH] announce-gen: Mention git commit in release announcement.

2024-05-12 Thread Paul Eggert

On 2024-05-12 12:50, Bruno Haible wrote:


Your real goal, which is — AFAIU — to allow distros to discard part
or all of the tarball and to redo the packaging work done by the release
manager in a different way, would be better served with a
   1) machine-readable file,
   2) somewhere in or in the vicinity of the tarball.


Although that's a good goal to have (see below), it's reasonably 
ambitious. For example, the tool lists we've been mentioning are 
incomplete, partly due to indirect dependencies (no glibc?) and partly 
not (no coreutils?) and it will be a pain to complete them (no firmware 
IDs? no motherboard or CPU IDs? you get the picture...). So I suspect 
that having an intermediate goal could be worthwhile.







In other words, if you really want to go this way — against the advice that
I gave you above —, better replace the two lines with:

   This release is based on the inetutils git, available at
 https://git.savannah.gnu.org/git/inetutils.git
   commit 524d4b6934db12b9f43be410d2f201fdb40cfc97, also labelled v1.42.


This is good advice. It's similar to wording I use in announcements of 
TZDB distributions (e.g., 
).


For what it's worth, those TZDB announcements have always intended to be 
human readable but various downstream projects parse the text and grab 
checksums and signatures and whatnot. The pull of automation is indeed 
strong, and your advice about going for automation is good.




Re: byteswap.h behavior

2024-05-12 Thread Paul Eggert

On 2024-05-12 12:47, Collin Funk wrote:

Yeah, I read the POSIX draft and it says that they may be macros. I
doubt the byteswap.h and endian.h functions are used with non-constant
expression arguments that often.


I sense a bit of confusion here. Although POSIX allows  
symbols like be16toh to be macros, I don't see where it allows 
be16toh(X) to evaluate X more than once, so an expression like 
be16toh(i++) has well-defined behavior even though it has a side effect.


A few function-like macros, like getc, are explicitly allowed to 
evaluate their arguments more than once, but ordinarily function-like 
macros are supposed to act like their corresponding functions.




Re: byteswap.h behavior

2024-05-12 Thread Paul Eggert

On 2024-05-12 12:23, Collin Funk wrote:

I think the best decision is to use
'extern inline' to match the behavior of glibc.


Yes, with the usual _GL_EXTERN business.



Also if we can agree upon making sure these are defined as functions,
what is the proper way to test it in a configure script? My instinct
tells me that assigning a function pointer to bswap_16, etc. would
fail if they are macros


I don't see the need to check that they are functions. POSIX does not 
require endian.h symbols like be16toh to be defined as functions, and 
the glibc manual doesn't mention endian.h, so it sounds like 
Gnulib-using code shouldn't assume that these symbols are functions.




Re: [PATCH 1/4] stdbit: new module

2024-05-12 Thread Paul Eggert

On 2024-05-12 11:43, Collin Funk wrote:

I have similar feelings about some stuff in gnulib-tool.py. We have
lines like this:

#
# Define GLImport class
#
class GLImport:


+1 on that. It's too close to the classic:

i = i + 1;  /* Add 1 to i.  */



Re: [PATCH] announce-gen: Mention git commit in release announcement.

2024-05-12 Thread Paul Eggert

On 2024-05-12 09:27, Jim Meyering wrote:

I like it. Wording and placement are spot on.


Looks good to me too.

I at first thought to suggest adding announce-gen's own version number 
to the announcement (to help people who want to check the announcement 
itself), but there's no need as it's derivable from Gnulib's version number.




Re: [PATCH 1/4] stdbit: new module

2024-05-12 Thread Paul Eggert

On 2024-05-11 23:48, Collin Funk wrote:

+# stddef_h.m4
+# serial 1

I see that you use my method of making sure files have license
headers, just copying another file. :)


Thanks, I fixed that.

Is this stuff documented somewhere in the .texi files? If not, I suppose 
it should be.


Frankly I continue to be annoyed by having to read and write a line "# 
FILENAME.m4" at the start of every m4 file FILENAME.m4. It's better for 
a file's first line to be a human-readable comment explaining what the 
file is for. Any automated procedure already knows the file name, so why 
do we need to put the name there manually, an error-prone process?




[PATCH] stdbit: don’t assume -DHAVE_CONFIG_H

2024-05-11 Thread Paul Eggert
This is needed for diffutils, which doesn’t define HAVE_CONFIG_H.
There needs to be some way for a test shared with glibc to discover
whether it should use the Gnulib or the glibc testing framework,
and I guess this is it.
* modules/stdbit-tests (GNULIB_TEST_STDBIT): Define.
* tests/tst-stdbit.h: Use GNULIB_TEST_STDBIT, not HAVE_CONFIG_H.
---
 ChangeLog| 10 ++
 modules/stdbit-tests |  2 ++
 tests/tst-stdbit.h   |  6 +++---
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 6154ef2bc8..3e5df0d22d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2024-05-11  Paul Eggert  
+
+   stdbit: don’t assume -DHAVE_CONFIG_H
+   This is needed for diffutils, which doesn’t define HAVE_CONFIG_H.
+   There needs to be some way for a test shared with glibc to discover
+   whether it should use the Gnulib or the glibc testing framework,
+   and I guess this is it.
+   * modules/stdbit-tests (GNULIB_TEST_STDBIT): Define.
+   * tests/tst-stdbit.h: Use GNULIB_TEST_STDBIT, not HAVE_CONFIG_H.
+
 2024-05-11  Collin Funk  
 
gnulib-tool.py: Filter out dependencies that cannot be found.
diff --git a/modules/stdbit-tests b/modules/stdbit-tests
index 4ef358aca9..a5832c84f2 100644
--- a/modules/stdbit-tests
+++ b/modules/stdbit-tests
@@ -23,6 +23,8 @@ libc-config
 stdint
 
 configure.ac:
+AC_DEFINE([GNULIB_TEST_STDBIT], [1],
+  [Define to 1 so that stdbit tests use the Gnulib framework, not glibc's.])
 
 Makefile.am:
 TESTS += \
diff --git a/tests/tst-stdbit.h b/tests/tst-stdbit.h
index b40d7447bf..0a0ab6b66c 100644
--- a/tests/tst-stdbit.h
+++ b/tests/tst-stdbit.h
@@ -19,14 +19,14 @@
 #ifndef _TST_STDBIT_H
 #define _TST_STDBIT_H
 
-#if HAVE_CONFIG_H
+#if GNULIB_TEST_STDBIT
 # include 
 #endif
 
 #include 
 #include 
 
-#if !HAVE_CONFIG_H
+#if !GNULIB_TEST_STDBIT
 # include 
 # include 
 #else
@@ -46,7 +46,7 @@ struct stdbit_test
   uint64_t res_8, res_16, res_32, res_64;
 };
 
-#if !HAVE_CONFIG_H
+#if !GNULIB_TEST_STDBIT
 # define TEST_TYPE(EXPR, TYPE) \
   _Static_assert (_Generic ((EXPR), TYPE: 1, default: 0), "bad type")
 #elif ((defined __GNUC__ && 2 <= __GNUC__) \
-- 
2.40.1




Re: gnulib-tool (Python) bug: "module count-one-bits doesn't exist"

2024-05-11 Thread Paul Eggert

On 2024-05-11 16:47, Collin Funk wrote:

Also in Emacs 'whitespace-mode' I noticed the lines that cause issues
use tabs instead of spaces. Shouldn't that be disallowed?


I'd allow tabs there, myself. In Gnulib we don't use leading tabs, but 
columnar tabs are OK, e.g., in build-aux/gcc-warning.spec.




gnulib-tool (Python) bug: "module count-one-bits doesn't exist"

2024-05-11 Thread Paul Eggert
I ran into a problem when using gnulib-tool on an earlier version of the 
new stdbit module. The problem went away when I had GNULIB_TOOL_IMPL=sh 
in the environment. The gnulib-tool code hasn't changed since the commit 
in question, so the gnulib-tool bug is presumably still there even 
though I've tweaked stdbit not to tickle the bug.


To reproduce it in a Gnulib repository, run these commands:

git checkout 4de6323d5d20996e51097a90f617cd4404a23eba
./gnulib-tool --create-testdir --dir foo -h stdbit

The failing output is as follows. I get this output on Fedora 40 x86-64.

gnulib-tool: warning: module count-leading-zeros doesn't exist
gnulib-tool: warning: module count-trailing-zerosdoesn't exist
gnulib-tool: warning: module count-one-bits  doesn't exist
Traceback (most recent call last):
  File "/home/eggert/src/gnu/gnulib/./.gnulib-tool.py", line 30, in 


main.main_with_exception_handling()
  File "/home/eggert/src/gnu/gnulib/pygnulib/main.py", line 1371, in 
main_with_exception_handling

main(temporary_directory)
  File "/home/eggert/src/gnu/gnulib/pygnulib/main.py", line 1073, in main
testdir.execute()
  File "/home/eggert/src/gnu/gnulib/pygnulib/GLTestDir.py", line 189, 
in execute

modules = moduletable.transitive_closure([requested_module])
  ^^
  File "/home/eggert/src/gnu/gnulib/pygnulib/GLModuleSystem.py", line 
853, in transitive_closure

duplicate_depmodule_names = [ depmodule.name
  ^^
AttributeError: 'NoneType' object has no attribute 'name'



[PATCH 4/4] stdbit: clean up namespace and simplify

2024-05-11 Thread Paul Eggert
Fix namespace pollution in substitute stdbit.h.
Clean up and simplify some of the non-GCC code, by preferring
inline functions to macros and substituting something
more straightforward than a de Bruijn hash (possibly faster?).
The non-GCC non-C23 substitutes should all compile to
branch-free code, if the compiler is good.
* lib/stdbit.c (COUNT_LEADING_ZEROS_INLINE)
(COUNT_TRAILING_ZEROS_INLINE, COUNT_ONE_BITS_INLINE): Remove.
(__gl_stdbit_clztab) [!_GL_STDBIT_HAS_BUILTIN_CLZ && !_MSC_VER]:
New constant array.
(__gl_stdbit_popcount_support): Adjust to stdbit.in.h changes.
* lib/stdbit.in.h: Do not include  or .
Check that bytes are 8 bits.
(COUNT_LEADING_ZEROS_INLINE, COUNT_TRAILING_ZEROS_INLINE)
(COUNT_ONE_BITS_INLINE, COUNT_LEADING_ZEROS)
(count_leading_zeros_32, count_leading_zeros)
(count_leading_zeros_l, count_leading_zeros_ll)
(COUNT_TRAILING_ZEROS, count_trailing_zeros_32)
(count_trailing_zeros, count_trailing_zeros_l)
(count_trailing_zeros_ll, COUNT_ONE_BITS, count_one_bits_32)
(COUNT_ONE_BITS_GENERIC, count_one_bits, count_one_bits_l)
(count_one_bits_ll): Remove, replacing all uses with ...
(_GL_STDBIT_HAS_BUILTIN_CLZ)
(_GL_STDBIT_HAS_BUILTIN_CTZ, _GL_STDBIT_HAS_BUILTIN_POPCOUNT)
(__gl_stdbit_clz, __gl_stdbit_clzl, __gl_stdbit_clzll)
(__gl_stdbit_ctz, __gl_stdbit_ctzl, __gl_stdbit_ctzll)
(__gl_stdbit_popcount, __gl_stdbit_popcountl, __gl_stdbit_popcountll)
(__gl_stdbit_popcount255): ... these new functions and macros.
(__popcnt64): Omit unnecessary casts.
(__gl_stdbit_popcount_support): Rename from popcount_support
and make it a signed char since that’s all we need.
(__gl_stdbit_popcount_supported): Rename from popcount_supported.
All uses changed.
* modules/stdbit (Depends-on): Add assert-h, for static_assert.
---
 ChangeLog   |  36 
 lib/stdbit.c|  50 -
 lib/stdbit.in.h | 553 +++-
 modules/stdbit  |   1 +
 4 files changed, 298 insertions(+), 342 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b0e7efd02c..b4319fc47b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,41 @@
 2024-05-11  Paul Eggert  
 
+   stdbit: clean up namespace and simplify
+   Fix namespace pollution in substitute stdbit.h.
+   Clean up and simplify some of the non-GCC code, by preferring
+   inline functions to macros and substituting something
+   more straightforward than a de Bruijn hash (possibly faster?).
+   The non-GCC non-C23 substitutes should all compile to
+   branch-free code, if the compiler is good.
+   * lib/stdbit.c (COUNT_LEADING_ZEROS_INLINE)
+   (COUNT_TRAILING_ZEROS_INLINE, COUNT_ONE_BITS_INLINE): Remove.
+   (__gl_stdbit_clztab) [!_GL_STDBIT_HAS_BUILTIN_CLZ && !_MSC_VER]:
+   New constant array.
+   (__gl_stdbit_popcount_support): Adjust to stdbit.in.h changes.
+   * lib/stdbit.in.h: Do not include  or .
+   Check that bytes are 8 bits.
+   (COUNT_LEADING_ZEROS_INLINE, COUNT_TRAILING_ZEROS_INLINE)
+   (COUNT_ONE_BITS_INLINE, COUNT_LEADING_ZEROS)
+   (count_leading_zeros_32, count_leading_zeros)
+   (count_leading_zeros_l, count_leading_zeros_ll)
+   (COUNT_TRAILING_ZEROS, count_trailing_zeros_32)
+   (count_trailing_zeros, count_trailing_zeros_l)
+   (count_trailing_zeros_ll, COUNT_ONE_BITS, count_one_bits_32)
+   (COUNT_ONE_BITS_GENERIC, count_one_bits, count_one_bits_l)
+   (count_one_bits_ll): Remove, replacing all uses with ...
+   (_GL_STDBIT_HAS_BUILTIN_CLZ)
+   (_GL_STDBIT_HAS_BUILTIN_CTZ, _GL_STDBIT_HAS_BUILTIN_POPCOUNT)
+   (__gl_stdbit_clz, __gl_stdbit_clzl, __gl_stdbit_clzll)
+   (__gl_stdbit_ctz, __gl_stdbit_ctzl, __gl_stdbit_ctzll)
+   (__gl_stdbit_popcount, __gl_stdbit_popcountl, __gl_stdbit_popcountll)
+   (__gl_stdbit_popcount255): ... these new functions and macros.
+   (__popcnt64): Omit unnecessary casts.
+   (__gl_stdbit_popcount_support): Rename from popcount_support
+   and make it a signed char since that’s all we need.
+   (__gl_stdbit_popcount_supported): Rename from popcount_supported.
+   All uses changed.
+   * modules/stdbit (Depends-on): Add assert-h, for static_assert.
+
stdbit: remove most module dependence
Remove dependence of stdbit on the modules count-leading-zeros,
count-trailing-zeros, and count-one-bits.  stdbit is part of C23
diff --git a/lib/stdbit.c b/lib/stdbit.c
index 2a5626a902..f2a51b10f7 100644
--- a/lib/stdbit.c
+++ b/lib/stdbit.c
@@ -1,9 +1,51 @@
+/* Support C23 bit and byte utilities on non-C23 platforms.
+
+   Copyright 2024 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 WARRAN

[PATCH 3/4] stdbit: remove most module dependence

2024-05-11 Thread Paul Eggert
Remove dependence of stdbit on the modules count-leading-zeros,
count-trailing-zeros, and count-one-bits.  stdbit is part of C23
and in the long run is more likely to be more portable, so code
should start preferring it.
* lib/stdbit.c (popcount_support): New var, if needed.
* lib/stdbit.in.h: Contain contents of count-leading-zeros.h,
count-trailing-zeros.h, and count-one-bits.h instead of including
those files.  In the long run those files should be stubs that are
implemented via stdbit.
* modules/stdbit (Depends-on): Do not depend on count-leading-zeros,
count-trailing-zeros, count-one-bits.
---
 ChangeLog   |  13 ++
 lib/stdbit.c|   6 +
 lib/stdbit.in.h | 357 +++-
 modules/stdbit  |   3 -
 4 files changed, 373 insertions(+), 6 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 083babb011..b0e7efd02c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,18 @@
 2024-05-11  Paul Eggert  
 
+   stdbit: remove most module dependence
+   Remove dependence of stdbit on the modules count-leading-zeros,
+   count-trailing-zeros, and count-one-bits.  stdbit is part of C23
+   and in the long run is more likely to be more portable, so code
+   should start preferring it.
+   * lib/stdbit.c (popcount_support): New var, if needed.
+   * lib/stdbit.in.h: Contain contents of count-leading-zeros.h,
+   count-trailing-zeros.h, and count-one-bits.h instead of including
+   those files.  In the long run those files should be stubs that are
+   implemented via stdbit.
+   * modules/stdbit (Depends-on): Do not depend on count-leading-zeros,
+   count-trailing-zeros, count-one-bits.
+
stdbit-tests: new module
* config/srclist.txt: Add files containing stdbit test cases
shared with glibc.
diff --git a/lib/stdbit.c b/lib/stdbit.c
index 0346ec095c..2a5626a902 100644
--- a/lib/stdbit.c
+++ b/lib/stdbit.c
@@ -1,3 +1,9 @@
 #include 
 #define _GL_STDBIT_INLINE _GL_EXTERN_INLINE
+#define COUNT_LEADING_ZEROS_INLINE _GL_EXTERN_INLINE
+#define COUNT_TRAILING_ZEROS_INLINE _GL_EXTERN_INLINE
+#define COUNT_ONE_BITS_INLINE _GL_EXTERN_INLINE
 #include 
+#if 1500 <= _MSC_VER && (defined _M_IX86 || defined _M_X64)
+int popcount_support = -1;
+#endif
diff --git a/lib/stdbit.in.h b/lib/stdbit.in.h
index 3701344498..63be4737a8 100644
--- a/lib/stdbit.in.h
+++ b/lib/stdbit.in.h
@@ -25,9 +25,360 @@
  #error "Please include config.h first."
 #endif
 
-#include 
-#include 
-#include 
+/* Taken from count-leading-zeros.h.  */
+#include 
+#include 
+
+_GL_INLINE_HEADER_BEGIN
+#ifndef COUNT_LEADING_ZEROS_INLINE
+# define COUNT_LEADING_ZEROS_INLINE _GL_INLINE
+#endif
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* Assuming the GCC builtin is BUILTIN and the MSC builtin is MSC_BUILTIN,
+   expand to code that computes the number of leading zeros of the local
+   variable 'x' of type TYPE (an unsigned integer type) and return it
+   from the current function.  */
+#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4) \
+|| (__clang_major__ >= 4)
+# define COUNT_LEADING_ZEROS(BUILTIN, MSC_BUILTIN, TYPE)\
+  return x ? BUILTIN (x) : CHAR_BIT * sizeof x;
+#elif _MSC_VER
+# pragma intrinsic (_BitScanReverse)
+# if defined _M_X64
+#  pragma intrinsic (_BitScanReverse64)
+# endif
+# define COUNT_LEADING_ZEROS(BUILTIN, MSC_BUILTIN, TYPE)\
+do  \
+  { \
+unsigned long result;   \
+if (MSC_BUILTIN (, x))   \
+  return CHAR_BIT * sizeof x - 1 - result;  \
+return CHAR_BIT * sizeof x; \
+  } \
+while (0)
+#else
+# define COUNT_LEADING_ZEROS(BUILTIN, MSC_BUILTIN, TYPE)\
+do  \
+  { \
+int count;  \
+unsigned int leading_32;\
+if (! x)\
+  return CHAR_BIT * sizeof x;   \
+for (count = 0; \
+ (leading_32 = ((x >> (sizeof (TYPE) * CHAR_BIT - 32))  \
+& 0xU), \
+  count < CHAR_BIT * sizeof x - 32 && !leading_32); \
+ count += 32)   \
+  x = x << 31 << 1;

[PATCH 2/4] stdbit-tests: new module

2024-05-11 Thread Paul Eggert
* config/srclist.txt: Add files containing stdbit test cases
shared with glibc.
* modules/stdbit-tests: New file.
* tests/support/test-driver.c, tests/tst-stdbit.h:
New files, copied from glibc with changes.
* tests/tst-stdc_bit_ceil.c:
* tests/tst-stdc_bit_floor.c, tests/tst-stdc_bit_width.c:
* tests/tst-stdc_count_ones.c, tests/tst-stdc_count_zeros.c:
* tests/tst-stdc_first_leading_one.c:
* tests/tst-stdc_first_leading_zero.c:
* tests/tst-stdc_first_trailing_one.c:
* tests/tst-stdc_first_trailing_zero.c:
* tests/tst-stdc_has_single_bit.c, tests/tst-stdc_leading_ones.c:
* tests/tst-stdc_leading_zeros.c, tests/tst-stdc_trailing_ones.c:
* tests/tst-stdc_trailing_zeros.c:
New files, copied verbatim from glibc.
---
 ChangeLog|  18 +++
 config/srclist.txt   |  15 ++
 lib/stdbit.in.h  | 115 +++---
 modules/stdbit-tests |  42 +
 tests/support/test-driver.c  |   5 +
 tests/tst-stdbit.h   | 225 +++
 tests/tst-stdc_bit_ceil.c|  88 +++
 tests/tst-stdc_bit_floor.c   |  88 +++
 tests/tst-stdc_bit_width.c   |  88 +++
 tests/tst-stdc_count_ones.c  |  88 +++
 tests/tst-stdc_count_zeros.c |  88 +++
 tests/tst-stdc_first_leading_one.c   |  88 +++
 tests/tst-stdc_first_leading_zero.c  |  88 +++
 tests/tst-stdc_first_trailing_one.c  |  88 +++
 tests/tst-stdc_first_trailing_zero.c |  88 +++
 tests/tst-stdc_has_single_bit.c  |  88 +++
 tests/tst-stdc_leading_ones.c|  88 +++
 tests/tst-stdc_leading_zeros.c   |  88 +++
 tests/tst-stdc_trailing_ones.c   |  88 +++
 tests/tst-stdc_trailing_zeros.c  |  88 +++
 20 files changed, 1592 insertions(+), 60 deletions(-)
 create mode 100644 modules/stdbit-tests
 create mode 100644 tests/support/test-driver.c
 create mode 100644 tests/tst-stdbit.h
 create mode 100644 tests/tst-stdc_bit_ceil.c
 create mode 100644 tests/tst-stdc_bit_floor.c
 create mode 100644 tests/tst-stdc_bit_width.c
 create mode 100644 tests/tst-stdc_count_ones.c
 create mode 100644 tests/tst-stdc_count_zeros.c
 create mode 100644 tests/tst-stdc_first_leading_one.c
 create mode 100644 tests/tst-stdc_first_leading_zero.c
 create mode 100644 tests/tst-stdc_first_trailing_one.c
 create mode 100644 tests/tst-stdc_first_trailing_zero.c
 create mode 100644 tests/tst-stdc_has_single_bit.c
 create mode 100644 tests/tst-stdc_leading_ones.c
 create mode 100644 tests/tst-stdc_leading_zeros.c
 create mode 100644 tests/tst-stdc_trailing_ones.c
 create mode 100644 tests/tst-stdc_trailing_zeros.c

diff --git a/ChangeLog b/ChangeLog
index 1019917f36..083babb011 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,23 @@
 2024-05-11  Paul Eggert  
 
+   stdbit-tests: new module
+   * config/srclist.txt: Add files containing stdbit test cases
+   shared with glibc.
+   * modules/stdbit-tests: New file.
+   * tests/support/test-driver.c, tests/tst-stdbit.h:
+   New files, copied from glibc with changes.
+   * tests/tst-stdc_bit_ceil.c:
+   * tests/tst-stdc_bit_floor.c, tests/tst-stdc_bit_width.c:
+   * tests/tst-stdc_count_ones.c, tests/tst-stdc_count_zeros.c:
+   * tests/tst-stdc_first_leading_one.c:
+   * tests/tst-stdc_first_leading_zero.c:
+   * tests/tst-stdc_first_trailing_one.c:
+   * tests/tst-stdc_first_trailing_zero.c:
+   * tests/tst-stdc_has_single_bit.c, tests/tst-stdc_leading_ones.c:
+   * tests/tst-stdc_leading_zeros.c, tests/tst-stdc_trailing_ones.c:
+   * tests/tst-stdc_trailing_zeros.c:
+   New files, copied verbatim from glibc.
+
stdbit: new module
* doc/gnulib-tool.texi, doc/gnulib.texi: Mention it.
* doc/posix-headers/stdbit.texi, lib/stdbit.c, lib/stdbit.in.h:
diff --git a/config/srclist.txt b/config/srclist.txt
index 78f77aafd2..34ffd63aec 100644
--- a/config/srclist.txt
+++ b/config/srclist.txt
@@ -71,6 +71,21 @@ $LIBCSRC posix/regex.h   lib
 #$LIBCSRC posix/regex_internal.h   lib
 #$LIBCSRC posix/regexec.c  lib
 #$LIBCSRC stdlib/canonicalize   lib/canonicalize-lgpl.c
+#$LIBCSRC stdlib/tst-stdbit.h  tests
+$LIBCSRC stdlib/tst-stdc_bit_ceil.ctests
+$LIBCSRC stdlib/tst-stdc_bit_floor.c   tests
+$LIBCSRC stdlib/tst-stdc_bit_width.c   tests
+$LIBCSRC stdlib/tst-stdc_count_ones.c  tests
+$LIBCSRC stdlib/tst-stdc_count_zeros.c tests
+$LIBCSRC stdlib/tst-stdc_first_leading_one.c   tests
+$LIBCSRC stdlib/tst-stdc_first_leading_zero.c  tests
+$LIBCSRC stdlib/tst-stdc_first_trailing_one.c  tests
+$LIBCSRC stdlib/tst-stdc_first_trailing_zero.c tests
+$LIBCSRC stdlib/tst-stdc_has_single_bit.c  tests
+$LIBCSRC stdlib/tst-stdc_leading_ones.ctests
+$LIBCSRC stdlib/tst-stdc_leading_zeros.c   tests
+$LIBCSRC

[PATCH 1/4] stdbit: new module

2024-05-11 Thread Paul Eggert
* doc/gnulib-tool.texi, doc/gnulib.texi: Mention it.
* doc/posix-headers/stdbit.texi, lib/stdbit.c, lib/stdbit.in.h:
* m4/stdbit_h.m4, modules/stdbit:
New files.
---
 ChangeLog |   8 +
 doc/gnulib-tool.texi  |   1 +
 doc/gnulib.texi   |   2 +
 doc/posix-headers/stdbit.texi |  25 ++
 lib/stdbit.c  |   3 +
 lib/stdbit.in.h   | 640 ++
 m4/stdbit_h.m4|  19 +
 modules/stdbit|  44 +++
 8 files changed, 742 insertions(+)
 create mode 100644 doc/posix-headers/stdbit.texi
 create mode 100644 lib/stdbit.c
 create mode 100644 lib/stdbit.in.h
 create mode 100644 m4/stdbit_h.m4
 create mode 100644 modules/stdbit

diff --git a/ChangeLog b/ChangeLog
index da40ff41de..1019917f36 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2024-05-11  Paul Eggert  
+
+   stdbit: new module
+   * doc/gnulib-tool.texi, doc/gnulib.texi: Mention it.
+   * doc/posix-headers/stdbit.texi, lib/stdbit.c, lib/stdbit.in.h:
+   * m4/stdbit_h.m4, modules/stdbit:
+   New files.
+
 2024-05-11  Bruno Haible  
 
doc: Mention module execinfo.
diff --git a/doc/gnulib-tool.texi b/doc/gnulib-tool.texi
index 9ed30c2055..5a2fd19cac 100644
--- a/doc/gnulib-tool.texi
+++ b/doc/gnulib-tool.texi
@@ -585,6 +585,7 @@ This is true for the following POSIX or ISO C standardized 
header files:
 @item @code{spawn.h}
 @item @code{stdalign.h}
 @item @code{stdarg.h}
+@item @code{stdbit.h}
 @item @code{stddef.h}
 @item @code{stdint.h}
 @item @code{stdio.h}
diff --git a/doc/gnulib.texi b/doc/gnulib.texi
index 55cf6ebcc9..6cbd10619e 100644
--- a/doc/gnulib.texi
+++ b/doc/gnulib.texi
@@ -1082,6 +1082,7 @@ which (known) portability problems are not worked around 
by Gnulib.
 * stdalign.h::
 * stdarg.h::
 * stdatomic.h::
+* stdbit.h::
 * stdbool.h::
 * stdckdint.h::
 * stddef.h::
@@ -1174,6 +1175,7 @@ which (known) portability problems are not worked around 
by Gnulib.
 @include posix-headers/stdalign.texi
 @include posix-headers/stdarg.texi
 @include posix-headers/stdatomic.texi
+@include posix-headers/stdbit.texi
 @include posix-headers/stdbool.texi
 @include posix-headers/stdckdint.texi
 @include posix-headers/stddef.texi
diff --git a/doc/posix-headers/stdbit.texi b/doc/posix-headers/stdbit.texi
new file mode 100644
index 00..8870668a59
--- /dev/null
+++ b/doc/posix-headers/stdbit.texi
@@ -0,0 +1,25 @@
+@node stdbit.h
+@section @file{stdbit.h}
+
+Gnulib module: stdbit
+
+Portability problems fixed by Gnulib:
+@itemize
+@item
+This header file is missing on many non-C23 platforms:
+glibc 2.38, FreeBSD 14.0, NetBSD 10.0, OpenBSD 7.5,
+AIX 7.3, HP-UX 11.31, Solaris 11.4, mingw, MSVC 17, Android 15.
+@end itemize
+
+Portability problems not fixed by Gnulib:
+@itemize
+@item
+On older non-C23 platforms lacking @code{typeof} or equivalent, a call
+to @code{stdc_bit_floor} and @code{stdc_bit_ceil} may yield a type
+that is wider than its argument.  Although C23 seems to allow this,
+it differs from GNU behavior.
+
+@item
+On non-C23 platforms, type-generic functions apply portably only to
+the standard unsigned integer types specified by C17 or earlier.
+@end itemize
diff --git a/lib/stdbit.c b/lib/stdbit.c
new file mode 100644
index 00..0346ec095c
--- /dev/null
+++ b/lib/stdbit.c
@@ -0,0 +1,3 @@
+#include 
+#define _GL_STDBIT_INLINE _GL_EXTERN_INLINE
+#include 
diff --git a/lib/stdbit.in.h b/lib/stdbit.in.h
new file mode 100644
index 00..a2fff04772
--- /dev/null
+++ b/lib/stdbit.in.h
@@ -0,0 +1,640 @@
+/* stdbit.h - C23 bit and byte utilities for non-C23 platforms
+
+   Copyright 2024 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/>.  */
+
+/* Written by Paul Eggert.  */
+
+#ifndef STDBIT_H
+#define STDBIT_H 1
+
+/* This file uses _GL_INLINE, WORDS_BIGENDIAN.  */
+#if !_GL_CONFIG_H_INCLUDED
+ #error "Please include config.h first."
+#endif
+
+#include 
+#include 
+#include 
+
+/* An expression, preferably with the type of A, that has the value of B.  */
+#if ((defined __GNUC__ && 2 <= __GNUC__) \
+ || (defined __clang_major__ && 4 <= __clang_major__) \
+ || (defined __IBMC__ && 1210 <= __IBMC__ && defined __IBM__TYPEOF__) \
+ || (defined __SUNPRO_C && 0x5110 &

[PATCH 0/4] New stdbit module, for C23 style stdbit.h

2024-05-11 Thread Paul Eggert
These patches add a new module to support 
on non-C23 platforms that lack it, which is most platforms
these days: it's new in glibc 2.39 (released January)
and other platforms I consulted don't have it yet.

This first implementation takes the simple approach
of assuming that stdbit.h works if it exists, which
is good enough for the platforms I tested it on.
We can complicate later if needed, with include_next etc.

Paul Eggert (4):
  stdbit: new module
  stdbit-tests: new module
  stdbit: remove most module dependence
  stdbit: clean up namespace and simplify

 ChangeLog|  75 +++
 config/srclist.txt   |  15 +
 doc/gnulib-tool.texi |   1 +
 doc/gnulib.texi  |   2 +
 doc/posix-headers/stdbit.texi|  25 +
 lib/stdbit.c |  51 ++
 lib/stdbit.in.h  | 863 +++
 m4/stdbit_h.m4   |  19 +
 modules/stdbit   |  42 ++
 modules/stdbit-tests |  42 ++
 tests/support/test-driver.c  |   5 +
 tests/tst-stdbit.h   | 225 +++
 tests/tst-stdc_bit_ceil.c|  88 +++
 tests/tst-stdc_bit_floor.c   |  88 +++
 tests/tst-stdc_bit_width.c   |  88 +++
 tests/tst-stdc_count_ones.c  |  88 +++
 tests/tst-stdc_count_zeros.c |  88 +++
 tests/tst-stdc_first_leading_one.c   |  88 +++
 tests/tst-stdc_first_leading_zero.c  |  88 +++
 tests/tst-stdc_first_trailing_one.c  |  88 +++
 tests/tst-stdc_first_trailing_zero.c |  88 +++
 tests/tst-stdc_has_single_bit.c  |  88 +++
 tests/tst-stdc_leading_ones.c|  88 +++
 tests/tst-stdc_leading_zeros.c   |  88 +++
 tests/tst-stdc_trailing_ones.c   |  88 +++
 tests/tst-stdc_trailing_zeros.c  |  88 +++
 26 files changed, 2597 insertions(+)
 create mode 100644 doc/posix-headers/stdbit.texi
 create mode 100644 lib/stdbit.c
 create mode 100644 lib/stdbit.in.h
 create mode 100644 m4/stdbit_h.m4
 create mode 100644 modules/stdbit
 create mode 100644 modules/stdbit-tests
 create mode 100644 tests/support/test-driver.c
 create mode 100644 tests/tst-stdbit.h
 create mode 100644 tests/tst-stdc_bit_ceil.c
 create mode 100644 tests/tst-stdc_bit_floor.c
 create mode 100644 tests/tst-stdc_bit_width.c
 create mode 100644 tests/tst-stdc_count_ones.c
 create mode 100644 tests/tst-stdc_count_zeros.c
 create mode 100644 tests/tst-stdc_first_leading_one.c
 create mode 100644 tests/tst-stdc_first_leading_zero.c
 create mode 100644 tests/tst-stdc_first_trailing_one.c
 create mode 100644 tests/tst-stdc_first_trailing_zero.c
 create mode 100644 tests/tst-stdc_has_single_bit.c
 create mode 100644 tests/tst-stdc_leading_ones.c
 create mode 100644 tests/tst-stdc_leading_zeros.c
 create mode 100644 tests/tst-stdc_trailing_ones.c
 create mode 100644 tests/tst-stdc_trailing_zeros.c

--
2.44.0




Re: De-vendoring gnulib in Debian packages

2024-05-11 Thread Paul Eggert

On 2024-05-11 07:09, Simon Josefsson via Gnulib discussion list wrote:

I would assume that (some stripped down
version of) git is a requirement to do any useful work on any platform
these days, so maybe it isn't a problem


Yes, my impression also is that Git has migrated into the realm of 
cc/gcc in that everybody has it, so it can depend indirectly on a 
possibly earlier version of itself.


Although it is worrisome that our collective trusted computing base 
keeps growing, let's face it, if there's a security bug in Git we're all 
in big trouble anyway.




[PATCH] * doc/posix-headers/utmpx.texi: Update for glibc.

2024-05-07 Thread Paul Eggert
---
 doc/posix-headers/utmpx.texi | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/doc/posix-headers/utmpx.texi b/doc/posix-headers/utmpx.texi
index ac2404bdc4..be1a9018ec 100644
--- a/doc/posix-headers/utmpx.texi
+++ b/doc/posix-headers/utmpx.texi
@@ -29,10 +29,20 @@ The @code{struct utmpx} field @code{ut_addr} or 
@code{ut_addr_v6} or
 @code{ut_ss} does not exist on some platforms:
 macOS, FreeBSD, AIX, Solaris.
 @item
+On some platforms, the @code{struct utmpx} field @code{ut_tv} is not
+of type @code{struct timeval}.  Instead, it is a different
+struct with @code{tv_sec} and @code{tv_usec} members that may
+have different types than the members of @code{struct timeval}:
+glibc 2.39 on platforms where @code{time_t} was historically 32 bits
+and where log file formats were not changed when 64-bit @code{time_t}
+was introduced.
+@item
 On some platforms, this API does not support timestamps past the
 year 2038:
-glibc 2.38 on 32-bit platforms like x86 and ARM where @code{time_t}
-was historically 32 bits.
+glibc 2.39 on 32-bit platforms like x86 and ARM where @code{time_t}
+was historically 32 bits; however, glibc 2.40 is planned to support
+timestamps up to the year 2106, by changing @code{ut_tv.tv_sec}'s type
+to be a 32-bit unsigned integer.
 @item
 On some platforms, this header misbehaves if the @code{year2038} or
 @code{year2038-recommended} modules are used and the program is
-- 
2.44.0




[PATCH] nstrftime: use clearer code for padding

2024-05-07 Thread Paul Eggert
This also works around GCC bug 114965
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965>.
* lib/strftime.c (enum pad_style): New type.
(width_add, my_strftime, __strftime_internal):
Use it instead of checking the raw chars.
* tests/test-nstrftime.h (T): Test for the GCC bug.
---
 ChangeLog  | 10 +++
 lib/strftime.c | 65 --
 tests/test-nstrftime.h |  1 +
 3 files changed, 48 insertions(+), 28 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 54ac701a98..21f4039dfe 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2024-05-07  Paul Eggert  
+
+   nstrftime: use clearer code for padding
+   This also works around GCC bug 114965
+   <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965>.
+   * lib/strftime.c (enum pad_style): New type.
+   (width_add, my_strftime, __strftime_internal):
+   Use it instead of checking the raw chars.
+   * tests/test-nstrftime.h (T): Test for the GCC bug.
+
 2024-05-06  Simon Josefsson  
 
maintainer-makefile: Prohibit BSD4.3/SysV u_char etc types.
diff --git a/lib/strftime.c b/lib/strftime.c
index 684d910771..9b205e4802 100644
--- a/lib/strftime.c
+++ b/lib/strftime.c
@@ -141,6 +141,15 @@ extern char *tzname[];
? (a) >> (b) \
: ((a) + ((a) < 0)) / (1 << (b)) - ((a) < 0))
 
+enum pad_style
+{
+  ZERO_PAD,  /* (default) Pad with 0 unless format says otherwise.  */
+  ALWAYS_ZERO_PAD, /* '0' Always pad with 0.  */
+  SIGN_PAD,/* '+' Always output a sign.  */
+  SPACE_PAD,   /* '_' Pad with space.  */
+  NO_PAD   /* '-' Do not pad.  */
+};
+
 #define TM_YEAR_BASE 1900
 
 #ifndef __isleap
@@ -193,7 +202,7 @@ extern char *tzname[];
   do  \
 { \
   size_t _n = (n);\
-  size_t _w = pad == L_('-') || width < 0 ? 0 : width;\
+  size_t _w = pad == NO_PAD || width < 0 ? 0 : width;\
   size_t _incr = _n < _w ? _w : _n;   \
   if (_incr >= maxsize - i)   \
 { \
@@ -205,7 +214,7 @@ extern char *tzname[];
   if (_n < _w)\
 { \
   size_t _delta = _w - _n;\
-  if (pad == L_('0') || pad == L_('+'))   \
+  if (pad == ALWAYS_ZERO_PAD || pad == SIGN_PAD)  \
 memset_zero (p, _delta);  \
   else\
 memset_space (p, _delta); \
@@ -825,7 +834,7 @@ static CHAR_T const c_month_names[][sizeof "September"] =
 
 static size_t __strftime_internal (STREAM_OR_CHAR_T *, STRFTIME_ARG (size_t)
const CHAR_T *, const struct tm *,
-   bool, int, int, bool *
+   bool, enum pad_style, int, bool *
extra_args_spec LOCALE_PARAM);
 
 /* Write information from TP into S according to the format
@@ -841,7 +850,8 @@ my_strftime (STREAM_OR_CHAR_T *s, STRFTIME_ARG (size_t 
maxsize)
 {
   bool tzset_called = false;
   return __strftime_internal (s, STRFTIME_ARG (maxsize) format, tp, false,
-  0, -1, _called extra_args LOCALE_ARG);
+  ZERO_PAD, -1,
+  _called extra_args LOCALE_ARG);
 }
 libc_hidden_def (my_strftime)
 
@@ -853,7 +863,7 @@ static size_t
 __strftime_internal (STREAM_OR_CHAR_T *s, STRFTIME_ARG (size_t maxsize)
  const CHAR_T *format,
  const struct tm *tp, bool upcase,
- int yr_spec, int width, bool *tzset_called
+ enum pad_style yr_spec, int width, bool *tzset_called
  extra_args_spec LOCALE_PARAM)
 {
 #if defined _LIBC && defined USE_IN_EXTENDED_LOCALE_MODEL
@@ -977,7 +987,7 @@ __strftime_internal (STREAM_OR_CHAR_T *s, STRFTIME_ARG 
(size_t maxsize)
 
   for (f = format; *f != '\0'; width = -1, f++)
 {
-  int pad = 0;  /* Padding for number ('_', '-', '+', '0', or 0).  */
+  enum pad_style pad = ZERO_PAD;
   int modifier; /* Field modifier ('E', 'O', or 0).  */
   int digits = 0;   /* Max digits for numeric format.  */
   int number_value; /* Numeric value to be printed.  */
@

Re: header file substitutes

2024-05-05 Thread Paul Eggert

On 2024-05-04 15:33, Collin Funk wrote:


But I don't think C23 has the conversion macros:

 /* big endian 32 to host.  */
 uint32_t be32toh (uint32_t);
 /* little endian 32 to host.  */
 uint32_t le32toh (uint32_t);


Yes, those might be a good reason for a Gnulib endian module, to support 
endian.h GNU-style. Ideally it would be implemented by appealing to 
stdbit.h when that's helpful.




Since  seems resonably portable,


I assume you mean ? There's no  on my Ubuntu system.


 $ echo | gcc -dM -E - | grep 'ENDIAN'
 #define __ORDER_LITTLE_ENDIAN__ 1234
 #define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
 #define __ORDER_PDP_ENDIAN__ 3412
 #define __ORDER_BIG_ENDIAN__ 4321
 #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__


Although that's a start, we'll need more of course. Here's what I have 
so far for my prototype stdbit.in.h, but it needs more work. This sort 
of thing used to be even trickier (see gl_BIGENDIAN and gl_MULTIARCH) 
but I hope we can dispense with that complexity nowadays (by using 
something like the following complexity instead :-).


  /* Define the native endianness.  Prefer predefined macros to #include
 directives, to avoid namespace pollution.  */

  /* GCC and Clang define __BYTE_ORDER__ etc.
 ARM compilers define __BIG_ENDIAN etc.
 Oracle Studio defines __SUNPRO_C etc.
 Some platforms work only on little-endian platforms.  */
  #if (defined __BYTE_ORDER__ && defined __ORDER_BIG_ENDIAN__ \
   && defined __ORDER_LITTLE_ENDIAN__)
  # define __STDC_ENDIAN_BIG__ __ORDER_BIG_ENDIAN__
  # define __STDC_ENDIAN_LITTLE__ __ORDER_LITTLE_ENDIAN__
  # define __STDC_ENDIAN_NATIVE__ __BYTE_ORDER__
  #elif (defined __SUNPRO_C ? defined __sparc \
 : 0)
  # define __STDC_ENDIAN_NATIVE__ __STDC_ENDIAN_BIG__
  #elif ((defined __BYTE_ORDER__ && defined __ORDER_BIG_ENDIAN__ \
  && defined __ORDER_BIG_ENDIAN__) \
 ? __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
 : defined __SUNPRO_C ? !defined __sparc \
 : (defined _WIN32 || defined __CYGWIN__ || defined __EMX__ \
|| defined __MSDOS__ || defined __DJGPP__) ? 1 \
 : 0)
  # define __STDC_ENDIAN_NATIVE__ __STDC_ENDIAN_LITTLE__
  #else
  # ifdef __has_include
  #  if __has_include ()
  #   include 
  #  endif
  # endif
  # if defined __BIG_ENDIAN && defined __LITTLE_ENDIAN && defined 
__BYTE_ORDER

  #  define __STDC_ENDIAN_BIG__ __BIG_ENDIAN
  #  define __STDC_ENDIAN_LITTLE__ __LITTLE_ENDIAN
  #  define __STDC_ENDIAN_NATIVE__ __BYTE_ORDER
  # endif
  # if defined BIG_ENDIAN && defined LITTLE_ENDIAN && defined BYTE_ORDER
  #  define __STDC_ENDIAN_BIG__ BIG_ENDIAN
  #  define __STDC_ENDIAN_LITTLE__ LITTLE_ENDIAN
  #  define __STDC_ENDIAN_NATIVE__ BYTE_ORDER
  # endif
  #endif
  #ifndef __STDC_ENDIAN_BIG__
  # define __STDC_ENDIAN_BIG__ 4321
  #endif
  #ifndef __STDC_ENDIAN_LITTLE__
  # define __STDC_ENDIAN_LITTLE__ 1234
  #endif
  #ifndef __STDC_ENDIAN_NATIVE__
  /* __STDC_ENDIAN_NATIVE__ is not defined on this platform.
 If this doesn't suffice for you, please email a fix
 to .  */
  #endif




Re: gnulib-tool sh+py mismatch when updating Emacs

2024-05-04 Thread Paul Eggert

On 2024-05-04 16:03, Collin Funk wrote:


I noticed in your emacs/output.0 it says "Generated by GNU Autoconf 2.71".

I was using Autoconf 2.72 on my system.


Ah, I am using Autoconf 2.71, which is what's in /usr/bin/autoconf on 
Fedora 40. It comes from the autoconf-2.71-10.fc40.noarch package, which 
is the current version for Fedora 40.


Occasionlly I use bleeding-edge autoconf (even past 2.72) but that's 
only to test Autoconf, not other packages.




-diff -r $diff_options --exclude=__pycache__ -q . "$tmp" >/dev/null ||
+diff -r $diff_options --exclude=__pycache__ --exclude=autom4te.cache -q . 
"$tmp" >/dev/null ||


Looks good to me, thanks. (I didn't bother testing it on my old slow 
machine.)





Re: gnulib-tool sh+py mismatch when updating Emacs

2024-05-04 Thread Paul Eggert

On 2024-05-04 13:45, Collin Funk wrote:

I can't reproduce this (using Fedora 40).


That's odd, as I just now reproduced it on Fedora 40 x86-64 using the 
following from-scratch recipe:


  mkdir new empty 

  empty_home=$PWD/empty 

  cd new 

  git clone git://git.sv.gnu.org/emacs.git 

  (cd emacs && git checkout fd859fbea2e9d13e76db1c5295d9ddd1c5955d83) 

  git clone git://git.sv.gnu.org/gnulib.git 

  (cd gnulib && git checkout fde88b711c9b1df5b142444ac7b0bc2aa8892d3a) 

  cd emacs 

  env -i HOME="$empty_home" PATH=/usr/bin admin/merge-gnulib 



The attached build log shows what I got. The last 'grep' command shows 
the bug, as lib/gnulib.mk.in uses HAVE_OFF64_T without defining it.


This invocation of admin/merge-gnulib uses a nearly-empty environment 
and an empty home directory, to lessen any local changes I might have.


If it helps to debug, you can get a tarball of all the resulting Emacs 
directory (sans .git subdirectory) temporarily, here:


https://www.cs.ucla.edu/~eggert/emacs.tgz$ mkdir new empty
$ empty_home=$PWD/empty
$ cd new
$ git clone git://git.sv.gnu.org/emacs.git
Cloning into 'emacs'...
remote: Counting objects: 1102975, done.
remote: Compressing objects: 100% (198635/198635), done.
remote: Total 1102975 (delta 903465), reused 1098398 (delta 899028)
Receiving objects: 100% (1102975/1102975), 413.08 MiB | 21.93 MiB/s, done.
Resolving deltas: 100% (903465/903465), done.
Updating files: 100% (5266/5266), done.
$ (cd emacs && git checkout fd859fbea2e9d13e76db1c5295d9ddd1c5955d83)
Note: switching to 'fd859fbea2e9d13e76db1c5295d9ddd1c5955d83'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c 

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at fd859fbea2e Allow `letrec` binding without init expression
$ git clone git://git.sv.gnu.org/gnulib.git
Cloning into 'gnulib'...
remote: Counting objects: 295108, done.
remote: Compressing objects: 100% (35985/35985), done.
remote: Total 295108 (delta 261344), reused 292549 (delta 259017)
Receiving objects: 100% (295108/295108), 74.69 MiB | 11.59 MiB/s, done.
Resolving deltas: 100% (261344/261344), done.
$ (cd gnulib && git checkout fde88b711c9b1df5b142444ac7b0bc2aa8892d3a)
Note: switching to 'fde88b711c9b1df5b142444ac7b0bc2aa8892d3a'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c 

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at fde88b711c readutmp, boot-time: Work around a Cygwin 3.5.3 bug.
$ cd emacs
$ env -i HOME="$empty_home" PATH=/usr/bin admin/merge-gnulib
Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)
Checking for autoconf (need at least version 2.65) ... ok
Your system has the required tools.
Building aclocal.m4 ...
Running 'autoreconf -fi -I m4' ...
Building 'aclocal.m4' in exec ...
Running 'autoreconf -fi' in exec ...
Configuring local git repository...
'.git/config' -> '.git/config.~1~'
git config transfer.fsckObjects 'true'
git config diff.cpp.xfuncname '!^[ 
\t]*[A-Za-z_][A-Za-z_0-9]*:[[:space:]]*($|/[/*])
^((::[[:space:]]*)?[A-Za-z_][A-Za-z_0-9]*[[:space:]]*\(.*)$
^((#define[[:space:]]|DEFUN).*)$'
git config diff.elisp.xfuncname 
'^\([^[:space:]]*def[^[:space:]]+[[:space:]]+([^()[:space:]]+)'
git config diff.m4.xfuncname '^((m4_)?define|A._DEFUN(_ONCE)?)\([^),]*'
git config diff.make.xfuncname 
'^([$.[:alnum:]_].*:|[[:alnum:]_]+[[:space:]]*([*:+]?[:?]?|!?)=|define .*)'
git config diff.shell.xfuncname 
'^([[:space:]]*[[:alpha:]_][[:alnum:]_]*[[:space:]]*\(\)|[[:alpha:]_][[:alnum:]_]*=)'
git config diff.texinfo.xfuncname '^@node[[:space:]]+([^,[:space:]][^,]+)'
Installing git hooks...
'build-aux/git-hooks/commit-msg' -> '.git/hooks/commit-msg'
'build-aux/git-hooks/pre-commit' -> '.git/hooks/pre-commit'
'build-aux/git-hooks/prepare-commit-msg' -> '.git/hooks/prepare-commit-msg'
'build-aux/git-hooks/post-commit' -> '.git/hooks/post-commit'
'build-aux/git-hooks/pre-push' -> '.git/hooks/pre-push'
'build-aux/git-hooks/commit-msg-files.awk' -> '.git/hooks/commit-msg-files.awk'
'.git/hooks/applypatch-msg.sample' -> '.git/hooks/applypatch-msg'
'.git/hooks/pre-applypatch.sample' -> '.git/hooks/pre-applypatch'
You can now run './configure'.
Module list with included 

Re: header file substitutes

2024-05-04 Thread Paul Eggert

On 2024-05-04 13:54, Collin Funk wrote:

IIRC in  there is:

  #define __STDC_ENDIAN_LITTLE__ /* Unique constant */
  #define __STDC_ENDIAN_BIG__ /* Unique constant */
  #define __STDC_ENDIAN_NATIVE__ /* __STDC_ENDIAN_LITTLE__ or 
__STDC_ENDIAN_BIG__ */

probably with values taken from Glibc's  or BSD's
.

But, I think the next POSIX revision has  like Glibc which I
prefer.


If the past is any guide, an advantage of the C23 version is that in the 
long run it is likely to be more portable. POSIX is an extension of C.




Re: gnulib-tool problem with off64_t and Emacs

2024-05-04 Thread Paul Eggert

On 2024-05-04 10:43, Bruno Haible wrote:

but there was no "HAVE_OFF64_T = @HAVE_OFF64_T@" line

Strange. The AC_SUBST([HAVE_OFF64_T]) in m4/off64_t.m4 should produce
such a line.


My thought as well.



The fragile hackery is only needed because you've hit a bug


Yes. To be fair it could well be an Emacs bug. Whatever it is, it's 
currently a hassle.




Do you see the 'sys_types' module enabled? Or maybe it is only
conditionally enabled?


Yes, there is a sys_types section in lib/gnulib.mk.in, and yes, it is 
conditionally enabled. It's preceded by this:


  ## begin gnulib module sys_types
  ifeq (,$(OMIT_GNULIB_MODULE_sys_types))

The ifeq succeeds and sys/types.h is being built.

I can reproduce the problem in fresh emacs and gnulib checkout siblings 
(same commits as before) by running the following in the emacs 
directory. This invokes gnulib-tool directly instead of indirectly via 
admin/merge-gnulib:


  ../gnulib/gnulib-tool --dir= --conditional-dependencies --import 
--no-changelog --no-vc-files --gnu-make --makefile-name=gnulib.mk.in 
--avoid=access --avoid=btowc --avoid=chmod --avoid=close 
--avoid=crypto/af_alg --avoid=dup --avoid=fchdir --avoid=fstat 
--avoid=iswblank --avoid=iswctype --avoid=iswdigit --avoid=iswxdigit 
--avoid=langinfo --avoid=localename-unsafe-limited --avoid=lock 
--avoid=mbrtowc --avoid=mbsinit --avoid=memchr --avoid=mkdir 
--avoid=msvc-inval --avoid=msvc-nothrow --avoid=nl_langinfo 
--avoid=openat-die --avoid=opendir --avoid=pthread-h --avoid=raise 
--avoid=save-cwd --avoid=select --avoid=setenv --avoid=sigprocmask 
--avoid=stat --avoid=stdarg --avoid=threadlib --avoid=tzset 
--avoid=unsetenv --avoid=utime --avoid=utime-h --avoid=wchar 
--avoid=wcrtomb --avoid=wctype --avoid=wctype-h alignasof alloca-opt 
binary-io boot-time byteswap c-ctype c-strcase canonicalize-lgpl 
careadlinkat close-stream copy-file-range count-leading-zeros 
count-one-bits count-trailing-zeros crypto/md5 crypto/md5-buffer 
crypto/sha1-buffer crypto/sha256-buffer crypto/sha512-buffer d-type 
diffseq double-slash-root dtoastr dtotimespec dup2 environ execinfo 
faccessat fchmodat fcntl fcntl-h fdopendir file-has-acl filemode 
filename filevercmp flexmember fpieee free-posix fstatat fsusage fsync 
futimens getline getloadavg getopt-gnu getrandom gettime gettimeofday 
gitlog-to-changelog ieee754-h ignore-value intprops largefile libgmp 
lstat manywarnings memmem-simple mempcpy memrchr memset_explicit minmax 
mkostemp mktime nanosleep nproc nstrftime pathmax pipe2 pselect 
pthread_sigmask qcopy-acl readlink readlinkat regex sig2str sigdescr_np 
socklen stat-time std-gnu11 stdbool stdckdint stddef stdio stpcpy 
strnlen strnlen strtoimax symlink sys_stat sys_time tempname time-h 
time_r time_rz timegm timer-time timespec-add timespec-sub 
update-copyright unlocked-io utimensat vla warnings year2038




gnulib-tool problem with off64_t and Emacs

2024-05-04 Thread Paul Eggert
I had problems updating Emacs to use gnulib commit 
fde88b711c9b1df5b142444ac7b0bc2aa8892d3a along with emacs commit 
fd859fbea2e9d13e76db1c5295d9ddd1c5955d83 (these are the same commits as 
I mentioned earlier today). I reproduced it like this:


cd emacs
admin/merge-gnulib

The resulting lib/gnulib.mk.in had a line:

  -e 's|@''HAVE_OFF64_T''@|$(HAVE_OFF64_T)|g' \

but there was no "HAVE_OFF64_T = @HAVE_OFF64_T@" line, and this caused 
the "#if !@HAVE_OFF64_T@" line in lib/sys_types.in.h to become "#if !" 
in lib/sys/types.h which is a syntax error in C.


I plan to work around the problem in Emacs by changing 
admin/merge-gnulib to remove m4/off64_t.m4, and putting the following 
into configure.ac instead:


  # Emacs does not need to check for off64_t. 

  AC_DEFUN([gl_TYPE_OFF64_T], 

[HAVE_OFF64_T=1 


 AC_SUBST([HAVE_OFF64_T])])

This is of course fragile.

It strikes me that apps like Emacs and coreutils don't need (and 
shouldn't use) off64_t which was merely intended as a transitional type 
in the 1990s, so there should be some way for them to disable the 
off64_t business without the abovementioned sort of fragile hackery. A 
documented way to disable off64_t discovery should simplify 
configuration and make it less likely to run into glitches such as the 
one I ran into with Emacs.




Re: header file substitutes

2024-05-04 Thread Paul Eggert

On 2024-05-04 07:52, Bruno Haible wrote:

But who will want to use it,
as long as it's not portable?


I'm working on a Gnulib  that will work on pre-C23 platforms.

Eventually this should replace Gnulib's count-leading-zeros, 
count-trailing-zeros, and count-one-bits modules, which should be marked 
as obsolescent once we have a standard (and nicer) way to get that 
information.




gnulib-tool sh+py mismatch when updating Emacs

2024-05-04 Thread Paul Eggert
Some sort of locale problem? The issue seems to be benign, except that 
it's a false positive when testing.


To reproduce it, clone current gnulib (commit 
fde88b711c9b1df5b142444ac7b0bc2aa8892d3a) and current emacs (commit 
fd859fbea2e9d13e76db1c5295d9ddd1c5955d83) under the current directory, 
and then run:


cd emacs
LC_ALL=en_US.utf8 GNULIB_TOOL_IMPL=sh+py admin/merge-gnulib

Here's what happens on Ubuntu 23.10 x86-64:

$ GNULIB_TOOL_IMPL=sh+py admin/merge-gnulib
Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)
Checking for autoconf (need at least version 2.65) ... ok
Your system has the required tools.
Building aclocal.m4 ...
Running 'autoreconf -fi -I m4' ...
Building 'aclocal.m4' in exec ...
Running 'autoreconf -fi' in exec ...
Configuring local git repository...
'.git/config' -> '.git/config.~1~'
git config transfer.fsckObjects 'true'
git config diff.cpp.xfuncname '!^[ 
]*[A-Za-z_][A-Za-z_0-9]*:[[:space:]]*($|/[/*])

^((::[[:space:]]*)?[A-Za-z_][A-Za-z_0-9]*[[:space:]]*\(.*)$
^((#define[[:space:]]|DEFUN).*)$'
git config diff.elisp.xfuncname 
'^\([^[:space:]]*def[^[:space:]]+[[:space:]]+([^()[:space:]]+)'

git config diff.m4.xfuncname '^((m4_)?define|A._DEFUN(_ONCE)?)\([^),]*'
git config diff.make.xfuncname 
'^([$.[:alnum:]_].*:|[[:alnum:]_]+[[:space:]]*([*:+]?[:?]?|!?)=|define .*)'
git config diff.shell.xfuncname 
'^([[:space:]]*[[:alpha:]_][[:alnum:]_]*[[:space:]]*\(\)|[[:alpha:]_][[:alnum:]_]*=)'

git config diff.texinfo.xfuncname '^@node[[:space:]]+([^,[:space:]][^,]+)'
Installing git hooks...
'build-aux/git-hooks/commit-msg' -> '.git/hooks/commit-msg'
'build-aux/git-hooks/pre-commit' -> '.git/hooks/pre-commit'
'build-aux/git-hooks/prepare-commit-msg' -> '.git/hooks/prepare-commit-msg'
'build-aux/git-hooks/post-commit' -> '.git/hooks/post-commit'
'build-aux/git-hooks/pre-push' -> '.git/hooks/pre-push'
'build-aux/git-hooks/commit-msg-files.awk' -> 
'.git/hooks/commit-msg-files.awk'

'.git/hooks/applypatch-msg.sample' -> '.git/hooks/applypatch-msg'
'.git/hooks/pre-applypatch.sample' -> '.git/hooks/pre-applypatch'
You can now run './configure'.
../gnulib/gnulib-tool: *** gnulib-tool.py produced different files than 
gnulib-tool.sh! Compare /home/eggert/src/gnu/d/emacs and 
/home/eggert/src/gnu/d/glpyD3FBYw.

../gnulib/gnulib-tool: *** Stop.


The difference is between autom4te.cache/requests and 
../glpyD3FBYw/autom4te.cache/requests. They're sorted differently:


$ diff -ur ./autom4te.cache/requests ../glpyD3FBYw/autom4te.cache/requests
--- ./autom4te.cache/requests   2024-05-04 08:47:45.397566582 -0700
+++ ../glpyD3FBYw/autom4te.cache/requests	2024-05-04 08:46:41.307448492 
-0700

@@ -16,69 +16,69 @@
 'configure.ac'
   ],
   {
-'_LT_AC_TAGCONFIG' => 1,
-'LT_INIT' => 1,
-'AM_XGETTEXT_OPTION' => 1,
-'m4_sinclude' => 1,
-'_AM_COND_IF' => 1,
-'AM_PROG_MOC' => 1,
+'AM_GNU_GETTEXT' => 1,
+'AC_CANONICAL_BUILD' => 1,
 'AC_CONFIG_AUX_DIR' => 1,
+'AC_PROG_LIBTOOL' => 1,
+'m4_include' => 1,
+'AM_CONDITIONAL' => 1,
+'AM_PROG_MKDIR_P' => 1,
+'_AM_SUBST_NOTMAKE' => 1,
+'AM_EXTRA_RECURSIVE_TARGETS' => 1,
+'AC_DEFINE_TRACE_LITERAL' => 1,
+'AC_FC_FREEFORM' => 1,
+'m4_pattern_forbid' => 1,
+'AM_INIT_AUTOMAKE' => 1,
 'LT_CONFIG_LTDL_DIR' => 1,
 'AC_CANONICAL_SYSTEM' => 1,
-'AC_CANONICAL_BUILD' => 1,
-'_AM_COND_ELSE' => 1,
+'AC_FC_PP_DEFINE' => 1,
+'LT_INIT' => 1,
+'AC_FC_SRCEXT' => 1,
+'AC_LIBSOURCE' => 1,
 'AC_CONFIG_LIBOBJ_DIR' => 1,
-'AM_PROG_CXX_C_O' => 1,
+'AM_PROG_FC_C_O' => 1,
 'AC_CONFIG_HEADERS' => 1,
-'AM_GNU_GETTEXT' => 1,
+'_AM_COND_ELSE' => 1,
+'AC_CONFIG_SUBDIRS' => 1,
+'AM_PROG_CXX_C_O' => 1,
+'m4_sinclude' => 1,
+'AM_MAKEFILE_INCLUDE' => 1,
 'AM_PROG_LIBTOOL' => 1,
+'AC_INIT' => 1,
+'include' => 1,
+'_AM_COND_ENDIF' => 1,
+'AM_POT_TOOLS' => 1,
+'AM_MAINTAINER_MODE' => 1,
+'_LT_AC_TAGCONFIG' => 1,
+'_AM_MAKEFILE_INCLUDE' 

Re: doc: Add appendix about Gnulib history

2024-05-04 Thread Paul Eggert

On 2024-05-03 17:14, Collin Funk wrote:

Also about this comment in intprops-internal.h:

 /* This include file assumes that signed types are two's complement without
padding bits; the above macros have undefined behavior otherwise.
If this is a problem for you, please let us know how to fix it for your 
host.
This assumption is tested by the intprops-tests module.  */

If you want to check this at compile time I think this should work:


Not quite, because it doesn't check for padding bits. Also, your code 
assumes that preprocessor arithmetic works the same as runtime 
arithmetic. Although C23 guarantees this (because it guarantees two's 
complement) I don't think C17 and earlier do. If memory serves, they 
even allow mixed-runtime systems, where arithmetic is sometimes ones' 
complement and sometimes two's. (Almost nobody cares about this 
theoretical possibility of course, which is why the Gnulib manual says 
not to worry about it.)




Re: doc: Add appendix about Gnulib history

2024-05-03 Thread Paul Eggert

On 2024-05-03 14:14, Collin Funk wrote:

The macros for compilers who don't support GCC's builtins are
really clever. They don't look like they were too much fun to write
though. :)


Actually they were fun in a twisted sort of way. My secret was to not 
work on them more than 30 minutes at a time (to prevent going crazy...).




Re: [PATCH 1/2] stddef: work around GCC 14 stddef.h bugs

2024-05-01 Thread Paul Eggert

On 2024-05-01 15:32, Bruno Haible wrote:

I tried another workaround, consisting of adding
   #undef __STDC_VERSION_STDDEF_H__
at the appropriate place, but then the Fedora 40 gcc gives a warning
about this #undef. Since neither the warning about the redefinition
nor the warning about the #undef can be silenced via
   #pragma GCC diagnostic ignored "-W..."
this approach did not work.


Yes, that was the workaround I tried first, and I rejected it for the 
same reason you did.


What a mess, huh?



[PATCH] intprops: document fix for GCC bug 68193

2024-04-30 Thread Paul Eggert
* lib/intprops-internal.h (_GL__GENERIC_BOGUS):
GCC bug 68193 is fixed in GCC 14.  This is just for documentation,
as _GL__GENERIC_BOGUS is not consulted in GCC 14.
---
 ChangeLog   | 7 +++
 lib/intprops-internal.h | 4 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index bf68bf6369..e2c736f854 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2024-04-30  Paul Eggert  
+
+   intprops: document fix for GCC bug 68193
+   * lib/intprops-internal.h (_GL__GENERIC_BOGUS):
+   GCC bug 68193 is fixed in GCC 14.  This is just for documentation,
+   as _GL__GENERIC_BOGUS is not consulted in GCC 14.
+
 2024-04-30  Bruno Haible  
 
*printf: Don't invoke gl_PRINTF_DIRECTIVE_N when it's not needed.
diff --git a/lib/intprops-internal.h b/lib/intprops-internal.h
index b5ba8d7cbd..443024c665 100644
--- a/lib/intprops-internal.h
+++ b/lib/intprops-internal.h
@@ -185,10 +185,10 @@
 /* Nonzero if this compiler has GCC bug 68193 or Clang bug 25390.  See:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193
https://llvm.org/bugs/show_bug.cgi?id=25390
-   For now, assume all versions of GCC-like compilers generate bogus
+   For now, assume GCC < 14 and all Clang versions generate bogus
warnings for _Generic.  This matters only for compilers that
lack relevant builtins.  */
-#if __GNUC__ || defined __clang__
+#if (__GNUC__ && __GNUC__ < 14) || defined __clang__
 # define _GL__GENERIC_BOGUS 1
 #else
 # define _GL__GENERIC_BOGUS 0
-- 
2.44.0




Re: Pacify -Wmissing-variable-declarations in unit tests.

2024-04-28 Thread Paul Eggert

On 2024-04-28 04:03, Collin Funk wrote:

I will listen to the Makefile and*ignore*  them now, or disable them
if they start annoying me. :)


Another possibility is to make each such variable 'static' if it's OK to 
make it static, and to precede every other variable declaration like this:


int foo;

with a declaration like this:

extern int foo;

I do this sort of thing in code that's not a test case, as I find it 
helpful to put the extern declaration into a .h file so that it's tested 
for compatibility when other modules use it.


For test cases this is more a judgment call, but I prefer doing either 
the above or adjusting the warning flags, to ignoring warnings, as the 
other warnings can be useful at time.




Re: [PATCH 2/2] nullptr: work around GCC 14 nullptr sentinel bug

2024-04-27 Thread Paul Eggert

On 2024-04-27 15:17, Sam James wrote:

Someone might read this and wrongly think that "GCC 14"
is broken.

I'd just omit 14 here.


Good point as I think some of these bugs are also in GCC 13.x for some 
value of x.


I installed the attached. It's not quite what you asked for but I hope 
it addresses the issue.


From b2b3e3b754f865834c8c66f3b2f1d73fecea2216 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 27 Apr 2024 16:07:16 -0700
Subject: [PATCH] maint: be more precise and vague about GCC 14
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

In commentary, be specific about which particular GCC 14 prerelease is
meant when this matters, and don’t say “GCC 14” otherwise.
Prompted by a remark by Sam James in:
https://lists.gnu.org/r/bug-gnulib/2024-04/msg00484.html
---
 ChangeLog | 4 ++--
 doc/posix-headers/stddef.texi | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 34893ebff1..185daab415 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -31,10 +31,10 @@
 
 2024-04-27  Paul Eggert  
 
-	nullptr: work around GCC 14 nullptr sentinel bug
+	nullptr: work around GCC nullptr sentinel bug
 	* m4/nullptr.m4 (gl_NULLPTR): Work around GCC bug 114780.
 
-	stddef: work around GCC 14 stddef.h bugs
+	stddef: work around GCC stddef.h bugs
 	* lib/stddef.in.h: Do nothing if _@GUARD_PREFIX@_STDDEF_H is
 	defined, as stddef.h has already been included.  This works
 	around GCC bug 114870.
diff --git a/doc/posix-headers/stddef.texi b/doc/posix-headers/stddef.texi
index 0e331481aa..00860bade0 100644
--- a/doc/posix-headers/stddef.texi
+++ b/doc/posix-headers/stddef.texi
@@ -48,7 +48,7 @@ GCC 12, Clang 15, and other pre-2023 C compilers.
 @item
 Some platforms define @code{nullptr_t} even when @code{} is
 not included:
-GCC 14.0.
+GCC 14.0.1 20240411 (Red Hat 14.0.1-0).
 
 @item
 Some platforms provide an @code{offsetof} macro that cannot be used in
-- 
2.40.1



Re: ac_cv_sys_largefile_opts undocumented?

2024-04-27 Thread Paul Eggert

On 2024-04-27 15:39, dmitrii.pasech...@cs.ox.ac.uk wrote:

It's for nauty, a well-known program to deal with graph isomorphisms
etc. I've made a Gentoo patch herehttps://bugs.gentoo.org/921138
and I wanted to upstream it.


Oh my, that is indeed in an undocumented/hacky part of autoconf, one 
that I just changed in the master development sources a few days ago; see:


https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=b71143738516017f0e0d347a4025301c06c40254

From your patch, it appears that nauty isn't using config.h and instead 
has its own file nauty-h.in that it maintains itself. Perhaps you could 
lessen this sort of problem by having it use config.h instead, at least 
for some things. Failing that, you could instead assume that 
ac_cv_sys_largefile_opts's value is a compiler option if and only if it 
begins with "-"; that's easy to say in a shell case statement and though 
still hacky would be a bit less brittle than what you've got.




Re: gnulib-tool: Use the Python implementation by default

2024-04-27 Thread Paul Eggert

On 2024-04-27 11:49, Bruno Haible wrote:

   - In many recent systems, 'python3' exists and 'python' does not.
 This includes Ubuntu 23.10 and 24.04. (No idea why it's different
 on your machine.)


Oh, I see I have the python-is-python3 package installed on my Ubuntu 
platform. I had forgotten that Debian wants users by default to live in 
a compatibility hell where the 'python' command does not work.



I have not seen a single system where 'python' exists, is version 3, and
'python3' does not exist.


I was thinking more of the future, where I expect such systems to exist. 
I suppose we can wait until then.




Re: ac_cv_sys_largefile_opts undocumented?

2024-04-27 Thread Paul Eggert

On 2024-04-27 14:06, dmitrii.pasech...@cs.ox.ac.uk wrote:

Thus I got questions whether a patch for a build system I submitted for
a project is OK, as it uses an undocumented variable (thus, perhaps,
unstable).


Although it's poorly designed and not documented and not stable, the 
patch may be good anyway. What's the patch for?




Re: gnulib-tool: Use the Python implementation by default

2024-04-27 Thread Paul Eggert

On 2024-04-27 06:32, Bruno Haible wrote:

Are there alternative Python implementations, which could be installed under
the name 'python3'?


On the platforms I currently have terminals open on (Fedora 40, Ubuntu 
23.10) it's called 'python'. You can also use 'python3' but I would 
suggest trying 'python' first if you aren't already doing that. These 
platforms do not have Python 2, which is typical nowadays.


There are other Python implementations - for example, GraalVM supports 
Python 3.8 and the GraalVM folks say they do a lot of compatibility 
checking. If people want (and have the time) to check portability of the 
new Python code in Gnulib, that might be a good alternative to try. 
Among other things, they claim a big performance improvement over 
CPython - I don't know how well that would work for us though.




Re: GNU gnulib: gnulib-tool has become much faster

2024-04-27 Thread Paul Eggert

On 2024-04-27 10:11, Tim Rühsen wrote:

Bruno, Dmitry, Collin, thank you so much !

The runtime improvement is amazing :)


Likewise. This is very much appreciated, especially on some of the 
trusty but old and slow hosts that I develop on.




[PATCH 2/2] nullptr: work around GCC 14 nullptr sentinel bug

2024-04-27 Thread Paul Eggert
* m4/nullptr.m4 (gl_NULLPTR): Work around GCC bug 114780.
---
 ChangeLog   |  3 +++
 doc/gnulib.texi |  4 
 m4/nullptr.m4   | 18 --
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b30238f934..e341b62968 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,8 @@
 2024-04-27  Paul Eggert  
 
+   nullptr: work around GCC 14 nullptr sentinel bug
+   * m4/nullptr.m4 (gl_NULLPTR): Work around GCC bug 114780.
+
stddef: work around GCC 14 stddef.h bugs
* lib/stddef.in.h: Do nothing if _@GUARD_PREFIX@_STDDEF_H is
defined, as stddef.h has already been included.  This works
diff --git a/doc/gnulib.texi b/doc/gnulib.texi
index ac8c01d1e1..aa0eb57f62 100644
--- a/doc/gnulib.texi
+++ b/doc/gnulib.texi
@@ -978,6 +978,10 @@ Portability problems fixed by Gnulib:
 Some platforms lack @code{nullptr}:
 For C: GCC 12, Clang 15, and other pre-2023 C compilers.
 For C++: pre-2011 C++ compilers.
+
+@item
+Some platforms incorrectly warn when @code{nullptr} is a sentinel argument:
+GCC 13.2 and 14.0.
 @end itemize
 
 Portability problems not fixed by Gnulib:
diff --git a/m4/nullptr.m4 b/m4/nullptr.m4
index e99495..4f2284296a 100644
--- a/m4/nullptr.m4
+++ b/m4/nullptr.m4
@@ -1,5 +1,5 @@
 # nullptr.m4
-# serial 1
+# serial 2
 dnl Copyright 2023-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,
@@ -14,7 +14,21 @@ AC_DEFUN([gl_NULLPTR],
  AC_CACHE_CHECK([for C nullptr], [gl_cv_c_nullptr],
[AC_COMPILE_IFELSE(
   [AC_LANG_SOURCE([[int *p = nullptr;]])],
-  [gl_cv_c_nullptr=yes],
+  [gl_cv_c_nullptr=yes
+   # Work around <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114780>.
+   gl_saved_CFLAGS=$CFLAGS
+   CFLAGS="$CFLAGS -Wall -Werror"
+   AC_COMPILE_IFELSE(
+ [AC_LANG_PROGRAM(
+[[void f (char const *, ...) __attribute__ ((sentinel));]],
+[[f ("", nullptr);]])],
+ [],
+ [AC_COMPILE_IFELSE(
+[AC_LANG_PROGRAM(
+   [[void f (char const *, ...) __attribute__ ((sentinel));]],
+   [[f ("", (void *) 0);]])],
+[gl_cv_c_nullptr='not as a sentinel'])])
+   CFLAGS=$gl_saved_CFLAGS],
   [gl_cv_c_nullptr=no])])
   gl_c_nullptr=$gl_cv_c_nullptr
   AC_LANG_POP([C])],
-- 
2.44.0




[PATCH 1/2] stddef: work around GCC 14 stddef.h bugs

2024-04-27 Thread Paul Eggert
* lib/stddef.in.h: Do nothing if _@GUARD_PREFIX@_STDDEF_H is
defined, as stddef.h has already been included.  This works
around GCC bug 114870.
(_GCC_NULLPTR_T): Define if needed to work around GCC bug 114869.
* m4/stddef_h.m4 (gl_STDDEF_H, gl_STDDEF_H_DEFAULTS):
* modules/stddef (stddef.h):
Detect the two bugs.
---
 ChangeLog | 11 +++
 doc/posix-headers/stddef.texi |  5 +
 lib/stddef.in.h   | 23 +--
 m4/stddef_h.m4| 32 +++-
 modules/stddef|  1 +
 5 files changed, 65 insertions(+), 7 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index dacf6892b1..b30238f934 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2024-04-27  Paul Eggert  
+
+   stddef: work around GCC 14 stddef.h bugs
+   * lib/stddef.in.h: Do nothing if _@GUARD_PREFIX@_STDDEF_H is
+   defined, as stddef.h has already been included.  This works
+   around GCC bug 114870.
+   (_GCC_NULLPTR_T): Define if needed to work around GCC bug 114869.
+   * m4/stddef_h.m4 (gl_STDDEF_H, gl_STDDEF_H_DEFAULTS):
+   * modules/stddef (stddef.h):
+   Detect the two bugs.
+
 2024-04-27  Bruno Haible  
 
bootstrap: Support checking out a recent GNULIB_REVISION.
diff --git a/doc/posix-headers/stddef.texi b/doc/posix-headers/stddef.texi
index 33ad48244c..0e331481aa 100644
--- a/doc/posix-headers/stddef.texi
+++ b/doc/posix-headers/stddef.texi
@@ -45,6 +45,11 @@ Some platforms fail to provide @code{nullptr_t},
 which Gnulib cannot usefully emulate:
 GCC 12, Clang 15, and other pre-2023 C compilers.
 
+@item
+Some platforms define @code{nullptr_t} even when @code{} is
+not included:
+GCC 14.0.
+
 @item
 Some platforms provide an @code{offsetof} macro that cannot be used in
 arbitrary expressions:
diff --git a/lib/stddef.in.h b/lib/stddef.in.h
index fa8998d9b7..fa249259cd 100644
--- a/lib/stddef.in.h
+++ b/lib/stddef.in.h
@@ -27,13 +27,18 @@
 #endif
 @PRAGMA_COLUMNS@
 
-#if defined __need_wchar_t || defined __need_size_t  \
-  || defined __need_ptrdiff_t || defined __need_NULL \
-  || defined __need_wint_t
+#if (!defined _@GUARD_PREFIX@_STDDEF_H \
+ && (defined __need_wchar_t || defined __need_size_t \
+ || defined __need_ptrdiff_t || defined __need_NULL \
+ || defined __need_wint_t))
 /* Special invocation convention inside gcc header files.  In
-   particular, gcc provides a version of  that blindly
-   redefines NULL even when __need_wint_t was defined, even though
-   wint_t is not normally provided by .  Hence, we must
+   particular,  in some ancient versions of GCC blindly
+   redefined NULL when __need_wint_t was defined, even though wint_t
+   is not normally provided by .
+   (FIXME: It's not clear what GCC versions those were - perhaps so
+   ancient that we can stop worrying about this?)
+   Although glibc 2.26 (2017) and later do not use __need_wint_t,
+   for portability to older Glibc + GCC,
remember if special invocation has ever been used to obtain wint_t,
in which case we need to clean up NULL yet again.  */
 
@@ -74,6 +79,12 @@ typedef long max_align_t;
 #   endif
 #  endif
 
+#  if !defined _GCC_NULLPTR_T && !@NULLPTR_T_NEEDS_STDDEF@
+/* Suppress unwanted nullptr_t typedef.  See
+   <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114869>.  */
+#   define _GCC_NULLPTR_T
+#  endif
+
 /* The include_next requires a split double-inclusion guard.  */
 
 #  @INCLUDE_NEXT@ @NEXT_STDDEF_H@
diff --git a/m4/stddef_h.m4 b/m4/stddef_h.m4
index 84d3bae801..0d4ddf8fcb 100644
--- a/m4/stddef_h.m4
+++ b/m4/stddef_h.m4
@@ -1,5 +1,5 @@
 # stddef_h.m4
-# serial 14
+# serial 15
 dnl Copyright (C) 2009-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,
@@ -84,6 +84,35 @@ AC_DEFUN_ONCE([gl_STDDEF_H],
 GL_GENERATE_STDDEF_H=true
   fi
 
+  dnl https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114869
+  AC_CACHE_CHECK([whether nullptr_t needs ],
+[gl_cv_nullptr_t_needs_stddef],
+[AC_COMPILE_IFELSE([AC_LANG_DEFINES_PROVIDED[nullptr_t x;]],
+   [gl_cv_nullptr_t_needs_stddef=no],
+   [gl_cv_nullptr_t_needs_stddef=yes])])
+  if test "$gl_cv_nullptr_t_needs_stddef" = no; then
+NULLPTR_T_NEEDS_STDDEF=0
+GL_GENERATE_STDDEF_H=true
+  fi
+
+  AC_CACHE_CHECK([for clean definition of __STDC_VERSION_STDDEF_H__],
+[gl_cv_clean_version_stddef],
+[AC_PREPROC_IFELSE(
+   [AC_LANG_SOURCE(
+  [[/* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114870 */
+#include 
+#undef __STDC_VERSION_STDDEF_H__
+#include 
+#ifdef __STDC_VERSION_STDDEF_H__
+# error " defines __STDC_VERSION_STDDEF_H__"
+#endif
+  ]])],
+[gl_cv_clean_version_stddef=yes],
+[gl_cv_clean_version_stddef=no])

Re: GNULIB_REVISION

2024-04-25 Thread Paul Eggert

On 4/25/24 10:43, Simon Josefsson wrote:


https://gitlab.com/gsasl/inetutils/-/jobs/6706396721


That's an malloc failure on the server side. The savannah admins should 
be told about the issue soon after it happens. Routine clones of GNU 
projects shouldn't fail like that. (It's never happened to me, but then 
I don't clone from Savannah all that often - maybe Savannah is giving 
less server memory to clients that seem to hog?)




Btw, using --depth 1 is incompatible with gnulib's git-version-gen


We could fix that by not requiring git-version-gen for the Gnulib 
submodule. git-version-gen is pretty useless for that anyway, as for 
Gnulib it currently outputs a string like "0.1.7513-648ae" which is not 
much more useful than the commit ID 
"648aeb575db7af9ddd51cf17d1b56ee91e9ef3c5".



Isn't the real problem that we don't put (for example) gzip's own
commit ID into the coreutils tarball? If we did that, Gnulib's commit
ID would come for free, since it can be derived from gzip's commit ID.


I suppose you meant s/coreutils/gzip/


Yes, sorry.


SHA1 git
commits aren't long-term stable either, since SHA1 is broken


As you say, they're good enough for now. And anyway I would think SHA1 
is good enough longer term unless an adversary infects your Git 
repository (and in that case you probably have bigger problems...).




Re: GNULIB_REVISION

2024-04-25 Thread Paul Eggert

You raise several good points. A couple of quick reaction:

On 2024-04-25 09:26, Simon Josefsson via Gnulib discussion list wrote:


- the gnulib git submodule is huge.  Not rarely I get out of memory
   errors during 'git clone' in CI/CD jobs.


First I've heard of this problem (other than with Git LFS, which Gnulib 
doesn't use). What part of the clone operation fails? Is this 
server-side RAM, or client-side RAM, or something else? How much memory 
does 'git clone' require now for Gnulib?


Is there some way to cajole 'git clone' into using less memory, with a 
'--depth 1' or similar options? Cloning shallowly would clone Gnulib a 
lot faster, if you're cloning from a remote repository.




- we don't offer any way for people receiving tarballs to learn which
   gnulib git commit was used


Isn't the real problem that we don't put (for example) gzip's own commit 
ID into the coreutils tarball? If we did that, Gnulib's commit ID would 
come for free, since it can be derived from gzip's commit ID.






Re: RFC: Remove documentation of IRIX as supported platform

2024-04-25 Thread Paul Eggert

This sounds good to me.

As far as IRIX goes, AC_SYS_LARGEFILE still works on 64-bit IRIX. Even 
32-bit IRIX should still work if you configure with CC='cc -n32', and 
this should be adequate for hobbyists who want to keep IRIX 5.3 going 
(some, by reverse engineering it! 
).




[PATCH] largefile: port to C++

2024-04-24 Thread Paul Eggert
This patch is mostly taken from Autoconf master.
* m4/largefile.m4 (AC_SYS_YEAR2038_RECOMMENDED):
Undefine if unpatched Autoconf 2.72 or earlier, so that
later code will redefine it.
The remaining part of this patch is from Autoconf master.
(_AC_SYS_YEAR2038_PROBE, _AC_SYS_LARGEFILE_PROBE):
Put "$CCFLAGS" in diagnostics, not "$CC".
(_AC_SYS_LARGEFILE_OPTIONS): Omit -n32.
(AC_SYS_LARGEFILE_PROBE): Fiddle with CPPFLAGS, not CC.
Do not worry about -n32.
---
 ChangeLog   | 12 
 m4/largefile.m4 | 33 -
 2 files changed, 32 insertions(+), 13 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 6564e09ac5..676aaef0be 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,17 @@
 2024-04-24  Paul Eggert  
 
+   largefile: port to C++
+   This patch is mostly taken from Autoconf master.
+   * m4/largefile.m4 (AC_SYS_YEAR2038_RECOMMENDED):
+   Undefine if unpatched Autoconf 2.72 or earlier, so that
+   later code will redefine it.
+   The remaining part of this patch is from Autoconf master.
+   (_AC_SYS_YEAR2038_PROBE, _AC_SYS_LARGEFILE_PROBE):
+   Put "$CCFLAGS" in diagnostics, not "$CC".
+   (_AC_SYS_LARGEFILE_OPTIONS): Omit -n32.
+   (AC_SYS_LARGEFILE_PROBE): Fiddle with CPPFLAGS, not CC.
+   Do not worry about -n32.
+
c32srtombs,mbsrtoc32s,mbsrtowcs,wcsrtombs: pacify GCC 14
* lib/c32srtombs-state.c (_gl_c32srtombs_state):
* lib/mbsrtoc32s-state.c (_gl_mbsrtoc32s_state):
diff --git a/m4/largefile.m4 b/m4/largefile.m4
index cf97e986a3..2f824089b0 100644
--- a/m4/largefile.m4
+++ b/m4/largefile.m4
@@ -26,9 +26,20 @@ AC_DEFUN([gl_SET_LARGEFILE_SOURCE],
  ]])
 )
 
+dnl Remove AC_SYS_YEAR2038_RECOMMENDED if unpatched Autoconf 2.72 or earlier.
+dnl Autoconf 2.72 still uses -n32, which is not a C preprocessor option,
+dnl and which was useful only on IRIX which is no longer supported.
+dnl This should be fixed in Autoconf 2.73.
+m4_ifdef([AC_SYS_YEAR2038_RECOMMENDED],
+  [m4_bmatch(m4_ifdef([_AC_SYS_LARGEFILE_OPTIONS],
+   [m4_defn([_AC_SYS_LARGEFILE_OPTIONS])],
+   ["-n32"]),
+ ["-n32"],
+   [m4_undefine([AC_SYS_YEAR2038_RECOMMENDED])])])
+
 m4_ifndef([AC_SYS_YEAR2038_RECOMMENDED], [
-# Support AC_SYS_YEAR2038_RECOMMENDED and related macros, even if
-# Autoconf 2.71 or earlier.  This code is taken from Autoconf master.
+# Fix up AC_SYS_YEAR2038_RECOMMENDED and related macros, even if
+# unpatched Autoconf 2.72 or earlier.  This code is taken from Autoconf master.
 
 # _AC_SYS_YEAR2038_TEST_CODE
 # --
@@ -77,7 +88,7 @@ m4_define([_AC_SYS_YEAR2038_OPTIONS], m4_normalize(
 # If you change this macro you may also need to change
 # _AC_SYS_YEAR2038_OPTIONS.
 AC_DEFUN([_AC_SYS_YEAR2038_PROBE],
-[AC_CACHE_CHECK([for $CC option for timestamps after 2038],
+[AC_CACHE_CHECK([for $CPPFLAGS option for timestamps after 2038],
   [ac_cv_sys_year2038_opts],
   [ac_save_CPPFLAGS="$CPPFLAGS"
   ac_opt_found=no
@@ -207,7 +218,6 @@ m4_define([_AC_SYS_LARGEFILE_OPTIONS], m4_normalize(
 ["none needed"]   dnl Most current systems
 ["-D_FILE_OFFSET_BITS=64"]dnl X/Open LFS spec
 ["-D_LARGE_FILES=1"]  dnl 32-bit AIX 4.2.1+, 32-bit z/OS
-["-n32"]  dnl 32-bit IRIX 6, SGI cc (obsolete)
 ))
 
 # _AC_SYS_LARGEFILE_PROBE
@@ -224,25 +234,25 @@ m4_define([_AC_SYS_LARGEFILE_OPTIONS], m4_normalize(
 # If you change this macro you may also need to change
 # _AC_SYS_LARGEFILE_OPTIONS.
 AC_DEFUN([_AC_SYS_LARGEFILE_PROBE],
-[AC_CACHE_CHECK([for $CC option to enable large file support],
+[AC_CACHE_CHECK([for $CPPFLAGS option for large files],
   [ac_cv_sys_largefile_opts],
-  [ac_save_CC="$CC"
+  [ac_save_CPPFLAGS=$CPPFLAGS
   ac_opt_found=no
   for ac_opt in _AC_SYS_LARGEFILE_OPTIONS; do
 AS_IF([test x"$ac_opt" != x"none needed"],
-  [CC="$ac_save_CC $ac_opt"])
+  [CPPFLAGS="$ac_save_CPPFLAGS $ac_opt"])
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([_AC_SYS_LARGEFILE_TEST_CODE])],
  [AS_IF([test x"$ac_opt" = x"none needed"],
[# GNU/Linux s390x and alpha need _FILE_OFFSET_BITS=64 for wide ino_t.
-CC="$CC -DFTYPE=ino_t"
+CPPFLAGS="$CPPFLAGS -DFTYPE=ino_t"
 AC_COMPILE_IFELSE([], [],
-  [CC="$CC -D_FILE_OFFSET_BITS=64"
+  [CPPFLAGS="$CPPFLAGS -D_FILE_OFFSET_BITS=64"
AC_COMPILE_IFELSE([], [ac_opt='-D_FILE_OFFSET_BITS=64'])])])
   ac_cv_sys_largefile_opts=$ac_opt
   ac_opt_found=yes])
 test $ac_opt_found = no || break
   done
-  CC="$ac_save_CC"
+  CPPFLAGS=$ac_save_CPPFLAGS
   dnl Gnulib implements large file support for native Windows, based on the
   dnl variables WINDOWS_64_BIT_OFF_T, WINDOWS_64_BIT_ST_SIZE.
  

Re: printf functions without INT_MAX limitation

2024-04-24 Thread Paul Eggert

On 4/22/24 7:21 AM, Bruno Haible wrote:


dealing with this problem means to define 2 functions instead of 1.


Since Gnulib is a source library, that complexity would be needed only 
for use inside object libraries - and these libraries already need to 
deal with off_t issues.




(Also, the problem will go away soon enough anyway, as 32-bit off_t
systems will likely die out by 2038 due to time_t issues of all things)


The problem will not entirely go away then. Only one function will be
needed then, but it will be platform-dependent whether its return type
is 'off_t' (standardized but 32-bit on Haiku) or 'off64_t' (always 64-bit
but not standardized). [1]


You lost me there. Although I don't use Haiku, my impression is that 
off_t is 64 bits on Haiku. See, for example, 
.




I think that the problem with regoff_t was that it already had legacy uses
and therefore could not move to 64 bits. A problem that we won't have with
'zoff_t'.


True, but now that you mention off64_t it strikes me that zoff_t would 
basically be off64_t, and off64_t has had its own problems: its only use 
in apps is to deal with deficient libraries, and it is a pain in 
libraries (where its only use is to deal with deficient apps :-). I 
don't offhand see why zoff_t would do any better than off64_t has done, 
or why we would need to give a new name to this unloved type.





[PATCH] c32srtombs,mbsrtoc32s,mbsrtowcs,wcsrtombs: pacify GCC 14

2024-04-24 Thread Paul Eggert
* lib/c32srtombs-state.c (_gl_c32srtombs_state):
* lib/mbsrtoc32s-state.c (_gl_mbsrtoc32s_state):
* lib/mbsrtowcs-state.c (_gl_mbsrtowcs_state):
* lib/wcsrtombs-state.c (_gl_wcsrtombs_state):
Add an extern decl for a “private” extern symbol, to pacify GCC
14’s -Wmissing-variable-declarations option.
---
 ChangeLog  | 10 ++
 lib/c32srtombs-state.c |  1 +
 lib/mbsrtoc32s-state.c |  1 +
 lib/mbsrtowcs-state.c  |  1 +
 lib/wcsrtombs-state.c  |  1 +
 5 files changed, 14 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index fa7b31bb40..6564e09ac5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2024-04-24  Paul Eggert  
+
+   c32srtombs,mbsrtoc32s,mbsrtowcs,wcsrtombs: pacify GCC 14
+   * lib/c32srtombs-state.c (_gl_c32srtombs_state):
+   * lib/mbsrtoc32s-state.c (_gl_mbsrtoc32s_state):
+   * lib/mbsrtowcs-state.c (_gl_mbsrtowcs_state):
+   * lib/wcsrtombs-state.c (_gl_wcsrtombs_state):
+   Add an extern decl for a “private” extern symbol, to pacify GCC
+   14’s -Wmissing-variable-declarations option.
+
 2024-04-24  Bruno Haible  
 
physmem: Port better to Linux.
diff --git a/lib/c32srtombs-state.c b/lib/c32srtombs-state.c
index 4cd95017ec..30d7b17bcc 100644
--- a/lib/c32srtombs-state.c
+++ b/lib/c32srtombs-state.c
@@ -20,6 +20,7 @@
 #include 
 
 /* Internal state used by the functions c32srtombs() and c32snrtombs().  */
+extern mbstate_t _gl_c32srtombs_state;
 mbstate_t _gl_c32srtombs_state
 /* The state must initially be in an "initial state"; so, zero-initialize it.
On most systems, putting it into BSS is sufficient.  Not so on Mac OS X 
10.3,
diff --git a/lib/mbsrtoc32s-state.c b/lib/mbsrtoc32s-state.c
index 4f6eeaa9db..6bcd4387db 100644
--- a/lib/mbsrtoc32s-state.c
+++ b/lib/mbsrtoc32s-state.c
@@ -20,6 +20,7 @@
 #include 
 
 /* Internal state used by the functions mbsrtoc32s() and mbsnrtoc32s().  */
+extern mbstate_t _gl_mbsrtoc32s_state;
 mbstate_t _gl_mbsrtoc32s_state
 /* The state must initially be in an "initial state"; so, zero-initialize it.
On most systems, putting it into BSS is sufficient.  Not so on Mac OS X 
10.3,
diff --git a/lib/mbsrtowcs-state.c b/lib/mbsrtowcs-state.c
index cbb8753b43..da036ec581 100644
--- a/lib/mbsrtowcs-state.c
+++ b/lib/mbsrtowcs-state.c
@@ -20,6 +20,7 @@
 #include 
 
 /* Internal state used by the functions mbsrtowcs() and mbsnrtowcs().  */
+extern mbstate_t _gl_mbsrtowcs_state;
 mbstate_t _gl_mbsrtowcs_state
 /* The state must initially be in an "initial state"; so, zero-initialize it.
On most systems, putting it into BSS is sufficient.  Not so on Mac OS X 
10.3,
diff --git a/lib/wcsrtombs-state.c b/lib/wcsrtombs-state.c
index 037887a57f..d22dfaee53 100644
--- a/lib/wcsrtombs-state.c
+++ b/lib/wcsrtombs-state.c
@@ -20,6 +20,7 @@
 #include 
 
 /* Internal state used by the functions wcsrtombs() and wcsnrtombs().  */
+extern mbstate_t _gl_wcsrtombs_state;
 mbstate_t _gl_wcsrtombs_state
 /* The state must initially be in an "initial state"; so, zero-initialize it.
On most systems, putting it into BSS is sufficient.  Not so on Mac OS X 
10.3,
-- 
2.44.0




Re: memset_explicit: Fix compilation error on some OpenSolaris derivatives

2024-04-24 Thread Paul Eggert

On 2024-04-23 20:50, Collin Funk wrote:

In pty.c we have:

 #include 
 #include "telnetd.h"

in telnetd.h:

  #include 


Why is telnetd.h including config.h? Only a top-level C file should 
include config.h, and it should so so at the start.





[PATCH] manywarnings: update C warnings for GCC 14

2024-04-24 Thread Paul Eggert
Adjust for C programs compiled by GCC 14.
(A C++ expert still needs to look at manywarnings-c++.m4.)
* build-aux/gcc-warning.spec: Add warnings introduced in GCC 13.
* m4/manywarnings.m4 (gl_MANYWARN_ALL_GCC):
Add -Wflex-array-member-not-at-end, -Wmissing-variable-declarations.
---
 ChangeLog  |  9 +
 build-aux/gcc-warning.spec | 20 +++-
 m4/manywarnings.m4 |  4 +++-
 3 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 58c7306f15..a5b5544b85 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2024-04-23  Paul Eggert  
+
+   manywarnings: update C warnings for GCC 14
+   Adjust for C programs compiled by GCC 14.
+   (A C++ expert still needs to look at manywarnings-c++.m4.)
+   * build-aux/gcc-warning.spec: Add warnings introduced in GCC 13.
+   * m4/manywarnings.m4 (gl_MANYWARN_ALL_GCC):
+   Add -Wflex-array-member-not-at-end, -Wmissing-variable-declarations.
+
 2024-04-23  Bruno Haible  
 
Update HACKING.
diff --git a/build-aux/gcc-warning.spec b/build-aux/gcc-warning.spec
index 09350012ba..e12fbe776e 100644
--- a/build-aux/gcc-warning.spec
+++ b/build-aux/gcc-warning.spec
@@ -13,6 +13,7 @@
 -Waliasing fortran
 -Walign-commonsfortran
 -Waligned-new=[none|global|all]c++
+-Walloc-size   enabled by -Wextra
 -Walloc-size-larger-than=   defaults to PTRDIFF_MAX
 -Walloc-zero   Gnulib fixes this problem
 -Walloca   we like alloca in small doses
@@ -34,6 +35,7 @@
 -Wanalyzer-file-leak   enabled by -fanalyzer
 -Wanalyzer-free-of-non-heapenabled by -fanalyzer
 -Wanalyzer-imprecise-fp-arithmetic enabled by -fanalyzer
+-Wanalyzer-infinite-loop   enabled by -fanalyzer
 -Wanalyzer-infinite-recursion  enabled by -fanalyzer
 -Wanalyzer-jump-through-null   enabled by -fanalyzer
 -Wanalyzer-malloc-leak enabled by -fanalyzer
@@ -41,18 +43,21 @@
 -Wanalyzer-null-argument   enabled by -fanalyzer
 -Wanalyzer-null-dereferenceenabled by -fanalyzer
 -Wanalyzer-out-of-bounds   enabled by -fanalyzer
+-Wanalyzer-overlapping-buffers enabled by -fanalyzer
 -Wanalyzer-possible-null-argument  enabled by -fanalyzer
 -Wanalyzer-possible-null-dereference   enabled by -fanalyzer
 -Wanalyzer-putenv-of-auto-var  enabled by -fanalyzer
 -Wanalyzer-shift-count-negativeenabled by -fanalyzer
 -Wanalyzer-shift-count-overflowenabled by -fanalyzer
 -Wanalyzer-stale-setjmp-buffer implied by -fanalyzer
+-Wanalyzer-symbol-too-complex  warns about compiler not about program
 -Wanalyzer-tainted-allocation-size FIXME requires -fanalyzer-checker=taint
 -Wanalyzer-tainted-array-index FIXME requires -fanalyzer-checker=taint
 -Wanalyzer-tainted-assertion   FIXME requires -fanalyzer-checker=taint
 -Wanalyzer-tainted-divisor FIXME requires -fanalyzer-checker=taint
 -Wanalyzer-tainted-offset  FIXME requires -fanalyzer-checker=taint
 -Wanalyzer-tainted-sizeFIXME requires 
-fanalyzer-checker=taint
+-Wanalyzer-undefined-behavior-strtok   enabled by -fanalyzer
 -Wanalyzer-va-arg-type-mismatchenabled by -fanalyzer
 -Wanalyzer-va-list-exhausted   enabled by -fanalyzer
 -Wanalyzer-va-list-leakenabled by -fanalyzer
@@ -93,11 +98,13 @@
 -Wc++20-compat c++
 -Wc++20-extensions c++
 -Wc++23-extensions c++
+-Wc++26-extensions c++
 -Wc++2a-compat c++
 -Wc-binding-type   fortran
--Wc11-c2x-compat   c compatibility
+-Wc11-c23-compat   c compatibility
 -Wc90-c99-compat   c compatibility
 -Wc99-c11-compat   c compatibility
+-Wcalloc-transposed-args   enabled by -Wextra
 -Wcannot-profile   default
 -Wcast-align   enabled by -Wcast-align=strict
 -Wcast-function-type   enabled by -Wextra
@@ -115,10 +122,12 @@
 -Wcomma-subscript  c++ and objc++
 -Wcomment  enabled by -Wall
 -Wcomments alias for -Wcomment
+-Wcompare-distinct-pointer-types   default
 -Wcompare-realsfortran
 -Wcomplain-wrong-lang  default
 -Wconditionally-supported  c++ and objc++
 -Wconversion   FIXME maybe? too much noise; encourages 
bad changes
+-Wcoverage-too-many-conditions default
 -Wconversion-extra fortran
 -Wconversion-null  c++ and objc++
 -Wcoverage-invalid

Re: Update HACKING

2024-04-23 Thread Paul Eggert

On 2024-04-23 12:41, Bruno Haible wrote:


?? That's not a difference between how I and how you work.


Oh, right, I got my directions confused. Sorry about the noise.




Re: Update HACKING

2024-04-23 Thread Paul Eggert

On 2024-04-23 08:03, Bruno Haible wrote:

+* We use a linear git history — no merges. To work in this setting, it's
+  recommended that you configure git with 'git config pull.rebase = true'.


I don't follow this recommendation: instead, I make sure that my master 
branch matches upstream exactly. That way, my commit IDs are identical 
to upstream and I don't need to worry about differences between 
origin/master and master. On the rare occasions when I find someone else 
has collided with me in pushing to master, I revert my local changes, 
pull (without either rebasing or merging), and then reapply my changes 
before pushing.


Also, even if one prefers pull rebasing, 'git config 
branch.autoSetupRebase always' might be gentler than 'guit config 
pull.rebase true' which is more blunderbussy.




+* Before pushing a commit, it is highly recommended that you review it in
+  its entirety. The easiest way to do so is to run
+$ gitk


I use 'git format-patch' and then read the patch; this works reasonably 
well for me. gitk is nice, but can be a hassle if I'm in Emacs or logged 
in remotely.




Re: GNU gnulib: calling for beta-testers

2024-04-22 Thread Paul Eggert

On 2024-04-21 03:52, Bruno Haible wrote:


5. Regenerate the fetched and generated files of your package. Depending on
the package, this may be a command such as

   $ ./bootstrap --no-git --gnulib-srcdir=$GNULIB_SRCDIR


I had a failure with this step when using current GNU diffutils 
(3d1a56b906c31cc6e89f6a9c008ba54d734d4ec2, which has a gnulib submodule 
with Gnulib commit 99ce3a004a2974c71f510f5df5bc6be7e2811d30) with 
current Gnulib (5b6e410e04b48c0fd62e954fafa220ef301d2c70) and building 
on Ubuntu 23.10 x86-64. Build log attached. To reproduce, clone 
diffutils and then:


  export GNULIB_TOOL_IMPL=sh+py
  ./bootstrap
  ./configure
  make -k distclean
  git submodule foreach git pull origin master
  git commit -m 'build: update gnulib submodule to latest' gnulib
  ./bootstrap --no-git --gnulib-srcdir=gnulib

The problem is that the Python-based build leaves behind a __pycache__ 
directory, which causes the comparison to fail.


diffutils-log.txt.gz
Description: application/gzip


Re: printf functions without INT_MAX limitation

2024-04-22 Thread Paul Eggert

On 2024-04-21 14:36, Bruno Haible wrote:


But direct use of off_t has two problems:
   - off_t is not defined by ISO C; thus it's an odd return type for things
 like zsprintf.


I was thinking that zsprintf should return ptrdiff_t and zprintf would 
return off_t. off_t is defined by POSIX , so it's reasonable 
for zprintf to use it.




   - off_t changes depending on whether gl_LARGEFILE is in use or not;
 thus it's a bad idea to use it in the API of any shared library or
 (more generally) any independently-built component.


That ship sailed long ago, I'm afraid. That is, any API depending on I/O 
sizes must deal with this problem anyway, so there's nothing new here. 
(Also, the problem will go away soon enough anyway, as 32-bit off_t 
systems will likely die out by 2038 due to time_t issues of all things)




I would prefer to solve this dilemma by defining a new type, say 'zoff_t',
that is required to be
   - at least as wide as off_t, and
   - at least as wide as ptrditt_t.


That should also work. Not sure whether it's better than using off_t for 
I/O and ptrdiff_t for main memory, though. Both approaches have pros and 
cons. An advantage of the off_t/ptrdiff_t approach is that it does not 
introduce a new type with all the confusion that would bring (there's a 
reason regoff_t has been so unpopular - even glibc doesn't implement it 
properly if memory serves...).




Re: GNU gnulib: calling for beta-testers

2024-04-22 Thread Paul Eggert

On 2024-04-21 15:27, Bruno Haible wrote:

ISO C, btw, is also "ever-changing"


Yes, plus if a language is not "ever-changing" it's dead.

The main thing to worry about is when old code stops working not when 
new language features get added. Since Python 3 came out Python has been 
reasonably good about dealing with deprecated features.




Re: future Python evolution

2024-04-22 Thread Paul Eggert

On 2024-04-21 15:38, Bruno Haible wrote:

Hi Paul,


But the concepts of the shell are stuck in the 40-years-ago past.


True, but keeping things simple allows for optimizations like PaSH that
can't reasonably be done to Python.

https://binpa.sh/


Well, I did try PaSh on gnulib-tool — this issue [1] is a testimony.


I agree that PaSh is not ready to tackle 'configure' scripts yet. 
However, it's promising and I wouldn't expect similar promise from 
Python script acceleration.


A better way to exploit PaSh would be to modify Autoconf to use it 
effectively. This of course would be nontrivial, though it shouldn't be 
*that* hard.




But what can you expect from a parallelization approach? On, say, a
quad-core processor you can expect at most a 4x speedup.


Quad-core is not the wave of the future. Even the three-year-old (and 
now discontinued) Xeon W-1350 I'm typing this on (which was trailing 
edge and bottom of the line when it came out - hey, I'm a cheapskate!) 
is 6 cores and 12 threads. And if you've been following recent CPU news 
you're aware of the big core counts coming down the pipeline. We should 
be engineering for these future systems, and not worry too much about 
yesterday's quad-core CPUs.


And if one can't get a decent single node to develop on, there's always 
DiSh on the horizon


https://github.com/binpash/dish




Re: printf functions without INT_MAX limitation

2024-04-21 Thread Paul Eggert

On 2024-04-21 09:27, Bruno Haible wrote:

2) Introduce variants of *printf functions, that return a 'ptrdiff_t' instead
of 'int'. (For results longer than PTRDIFF_MAX, they will fail with error
ENOMEM, not EOVERFLOW.) This gives rise to several new gnulib modules.


This sounds like a good idea. However, shouldn't output-oriented 
functions like 'printf' return off_t rather than ptrdiff_t?


Also, I'm tempted to use "#define printf zprintf" and leave most of the 
source code alone. Perhaps there should be a Gnulib option for that.




Re: future Python evolution

2024-04-21 Thread Paul Eggert

On 2024-04-21 07:50, Bruno Haible wrote:

But the concepts of the shell are stuck in the 40-years-ago past.


True, but keeping things simple allows for optimizations like PaSH that 
can't reasonably be done to Python.


https://binpa.sh/



Re: beta-tester call draft

2024-04-20 Thread Paul Eggert
I hope we can drop the sh implementation at the first opportunity - 
which would be after we've tested the Python implementation enough, and 
when we want to add some features and it's a pain to add them to both sh 
and Python.




Re: nan: Relicense under LGPLv2+

2024-04-20 Thread Paul Eggert

On 2024-04-17 16:09, Bruno Haible wrote:


Can I have your agreement to relicensing your contributions to this
module under LGPLv2+, please?


Yes, that's fine.




Re: beta-tester call draft

2024-04-19 Thread Paul Eggert

On 2024-04-19 17:22, Bruno Haible wrote:

Hi,



   2. Update your gnulib checkout. (For some packages, it comes as a
  git submodule named 'gnulib'.) Like this:
$ git pull
  Set the environment variable GNULIB_SRCDIR, pointing to this checkout.


Might help to spell out what to do with submodules. Something like this, 
perhaps:


  2. Update your gnulib checkout. If you are not using git submodules,
 like this:
   $ git pull
 and then set the environment variable GNULIB_SRCDIR, pointing to
 this checkout. If you are using git submodules, something like
 this:
   $ git -C gnulib pull origin master
   $ git commit -m 'build: update gnulib submodule to latest' gnulib



   5. Regenerate the fetched and generated files of your package.
  Depending on the packge, this may be a command such as
$ ./bootstrap --no-git --gnulib-srcdir=$GNULIB_SRCDIR
  or
$ export GNULIB_SRCDIR; ./autopull.sh; ./autogen.sh
  or, if no such script is available:
$ $GNULIB_SRCDIR/gnulib-tool --update


Here, perhaps you can add, "If you are using git submodules, just run a 
plain './bootstrap'."



  If there is a failure, due to differences between the 'sh' and 'py'
  results, please report it to .


I tried this on my well-worn copy of GNU diffutils, and got the 
following diagnostics. These were all diagnostics about backup files, or 
files I manually deleted by moving them into a '.del' subdirectory (an 
old habit of mine), or symlink loops that I had created to test.


Perhaps the advice should start with, "Start with a fresh checkout from 
Git."


-
diff: ./.del/gnulib-tests/test-fnmatch-1.sh: No such file or directory
diff: 
/home/eggert/src/gnu/glpyXeRWfy/.del/gnulib-tests/test-fnmatch-1.sh: No 
such file or directory

diff: ./.del/gnulib-tests/test-fnmatch-2.sh: No such file or directory
diff: 
/home/eggert/src/gnu/glpyXeRWfy/.del/gnulib-tests/test-fnmatch-2.sh: No 
such file or directory

diff: ./.del/gnulib-tests/test-fnmatch-3.sh: No such file or directory
diff: 
/home/eggert/src/gnu/glpyXeRWfy/.del/gnulib-tests/test-fnmatch-3.sh: No 
such file or directory

diff: ./.del/gnulib-tests/test-fnmatch-4.sh: No such file or directory
diff: 
/home/eggert/src/gnu/glpyXeRWfy/.del/gnulib-tests/test-fnmatch-4.sh: No 
such file or directory

diff: ./.del/gnulib-tests/test-fnmatch-5.sh: No such file or directory
diff: 
/home/eggert/src/gnu/glpyXeRWfy/.del/gnulib-tests/test-fnmatch-5.sh: No 
such file or directory

diff: ./.del/gnulib-tests/test-fnmatch-w32-1.sh: No such file or directory
diff: 
/home/eggert/src/gnu/glpyXeRWfy/.del/gnulib-tests/test-fnmatch-w32-1.sh: 
No such file or directory

diff: ./.del/gnulib-tests/test-fnmatch-w32-2.sh: No such file or directory
diff: 
/home/eggert/src/gnu/glpyXeRWfy/.del/gnulib-tests/test-fnmatch-w32-2.sh: 
No such file or directory

diff: ./.del/gnulib-tests/test-fnmatch-w32-3.sh: No such file or directory
diff: 
/home/eggert/src/gnu/glpyXeRWfy/.del/gnulib-tests/test-fnmatch-w32-3.sh: 
No such file or directory

diff: ./.del/gnulib-tests/test-fnmatch-w32-4.sh: No such file or directory
diff: 
/home/eggert/src/gnu/glpyXeRWfy/.del/gnulib-tests/test-fnmatch-w32-4.sh: 
No such file or directory

diff: ./.del/gnulib-tests/test-fnmatch-w32-5.sh: No such file or directory
diff: 
/home/eggert/src/gnu/glpyXeRWfy/.del/gnulib-tests/test-fnmatch-w32-5.sh: 
No such file or directory

diff: ./.del/gnulib-tests/test-fnmatch-w32-6.sh: No such file or directory
diff: 
/home/eggert/src/gnu/glpyXeRWfy/.del/gnulib-tests/test-fnmatch-w32-6.sh: 
No such file or directory

diff: ./.del/gnulib-tests/test-fnmatch-w32-7.sh: No such file or directory
diff: 
/home/eggert/src/gnu/glpyXeRWfy/.del/gnulib-tests/test-fnmatch-w32-7.sh: 
No such file or directory

diff: ./.del/gnulib-tests/test-fnmatch-w32.c: No such file or directory
diff: 
/home/eggert/src/gnu/glpyXeRWfy/.del/gnulib-tests/test-fnmatch-w32.c: No 
such file or directory

diff: ./.del/lib/mbszero.c: No such file or directory
diff: /home/eggert/src/gnu/glpyXeRWfy/.del/lib/mbszero.c: No such file 
or directory

diff: ./.del/lib/mbuiterf.c: No such file or directory
diff: /home/eggert/src/gnu/glpyXeRWfy/.del/lib/mbuiterf.c: No such file 
or directory

diff: ./.del/lib/mbuiterf.h: No such file or directory
diff: /home/eggert/src/gnu/glpyXeRWfy/.del/lib/mbuiterf.h: No such file 
or directory

diff: ./.del/lib/propername-lite.c: No such file or directory
diff: /home/eggert/src/gnu/glpyXeRWfy/.del/lib/propername-lite.c: No 
such file or directory

diff: ./gnulib-tests/rand-digit.h~: No such file or directory
diff: /home/eggert/src/gnu/glpyXeRWfy/gnulib-tests/rand-digit.h~: No 
such file or directory

diff: ./gnulib-tests/test-btowc1.sh~: No such file or directory
diff: /home/eggert/src/gnu/glpyXeRWfy/gnulib-tests/test-btowc1.sh~: No 
such file or directory

diff: ./gnulib-tests/test-btowc2.sh~: No such file or directory
diff: 

Re: bug#70411: [bug] install(1) fails to read /dev/stdin on Darwin

2024-04-19 Thread Paul Eggert

On 2024-04-18 14:52, Sergei Trofimovich wrote:

$ clang simple.c -o simple && echo 42 | ./simple
1: ino=3009428657538693161
2: ino=3009428657538693161
3: ino=1568241705

Note how stat() and fstat() don't agree on inode.

Apparently it's documented in
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/fstat.2.html
as

   BUGS
  Applying fstat to a socket (and thus to a pipe) returns a zero'd buffer,
  except for the blocksize field, and a unique device and inode number.


The BUGS note simply means that a pipe has a unique inode number, which 
is what we want. So that's not indicating any problem.



Oh, I see the problem now.  For a socket or pipe, macOS fstat returns 
the full 64-bit inode number, whereas macOS stat returns only the low 
order 32 bits.  In your example, 3009428657538693161 % (2**32) == 
1568241705.


This is a kernel bug in macOS. Can you report it or otherwise arrange to 
have the kernel bug fixed? I expect that you have better connections 
with Apple than I do. A proposed patch (relative to xnu-10063.101.15) is 
attached; I have not tested it as I don't use macOS. Thanks.


Also, I am documenting this macOS bug in Gnulib by installing the second 
attached patch to Gnulib, and am cc'ing this email to bug-gnulib.From 29345117a4cf85aceb88e3901758b19a4867062e Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Fri, 19 Apr 2024 00:12:50 -0700
Subject: [PATCH] Fix bug with stat truncating pipe/socket st_ino

Problem reported by Sergei Trofimovich in:
https://bugs.gnu.org/70411
https://github.com/NixOS/nixpkgs/pull/300797
* bsd/miscfs/devfs/devfs_fdesc_support.c (fdesc_attr):
Do not truncate inode numbers to 32 bits.
---
 bsd/miscfs/devfs/devfs_fdesc_support.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bsd/miscfs/devfs/devfs_fdesc_support.c b/bsd/miscfs/devfs/devfs_fdesc_support.c
index a17c6992..b4a55103 100644
--- a/bsd/miscfs/devfs/devfs_fdesc_support.c
+++ b/bsd/miscfs/devfs/devfs_fdesc_support.c
@@ -437,10 +437,10 @@ fdesc_attr(int fd, struct vnode_attr *vap, vfs_context_t a_context)
 	case DTYPE_PIPE:
 #if SOCKETS
 		if (FILEGLOB_DTYPE(fp->fp_glob) == DTYPE_SOCKET) {
-			error = soo_stat((struct socket *)fp_get_data(fp), (void *), 0);
+			error = soo_stat((struct socket *)fp_get_data(fp), (void *), 1);
 		} else
 #endif /* SOCKETS */
-		error = pipe_stat((struct pipe *)fp_get_data(fp), (void *), 0);
+		error = pipe_stat((struct pipe *)fp_get_data(fp), (void *), 1);
 
 		if (error == 0) {
 			if (FILEGLOB_DTYPE(fp->fp_glob) == DTYPE_SOCKET) {
-- 
2.44.0

From c2174a623d33096b52f4d7fd2963f76acb3e301f Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Fri, 19 Apr 2024 00:29:32 -0700
Subject: [PATCH] fstatat, stat: document macOS st_ino pipe bug

* doc/posix-functions/fstatat.texi (fstatat):
* doc/posix-functions/stat.texi (stat):
Document macOS bug (see <https://bugs.gnu.org/70411>).
---
 ChangeLog| 7 +++
 doc/posix-functions/fstatat.texi | 5 +
 doc/posix-functions/stat.texi| 5 +
 3 files changed, 17 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 7ce75a98a9..1667f90c55 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2024-04-19  Paul Eggert  
+
+	fstatat, stat: document macOS st_ino pipe bug
+	* doc/posix-functions/fstatat.texi (fstatat):
+	* doc/posix-functions/stat.texi (stat):
+	Document macOS bug (see <https://bugs.gnu.org/70411>).
+
 2024-04-18  Bruno Haible  
 
 	totalordermagl: Add tests.
diff --git a/doc/posix-functions/fstatat.texi b/doc/posix-functions/fstatat.texi
index e959a5cc73..90884e2eb1 100644
--- a/doc/posix-functions/fstatat.texi
+++ b/doc/posix-functions/fstatat.texi
@@ -40,5 +40,10 @@ This function does not fail when the second argument is an empty string
 on some platforms, even when @code{AT_EMPTY_PATH} is not used:
 glibc 2.7, Linux 2.6.38.
 @item
+This function sets @code{st_ino} only to the low-order 32 bits of
+the inode number of a socket or pipe, which thus can disagree
+with the @code{st_ino} obtained by @code{fstat}:
+macOS 14.
+@item
 @xref{sys/stat.h}, for general portability problems with @code{struct stat}.
 @end itemize
diff --git a/doc/posix-functions/stat.texi b/doc/posix-functions/stat.texi
index f655451392..8afd3b17bb 100644
--- a/doc/posix-functions/stat.texi
+++ b/doc/posix-functions/stat.texi
@@ -50,6 +50,11 @@ Portability problems not fixed by Gnulib:
 Cygwin's @code{stat} function sometimes sets @code{errno} to @code{EACCES} when
 @code{ENOENT} would be more appropriate.
 @item
+This function sets @code{st_ino} only to the low-order 32 bits of
+the inode number of a socket or pipe, which thus can disagree
+with the @code{st_ino} obtained by @code{fstat}:
+macOS 14.
+@item
 Because of the definition of @code{struct stat}, it is not possible to
 portably replace @code{stat} via an object-like macro.  Therefore,
 expressions such as @code{(islnk ? lstat : stat) (name, buf)} are not
-- 
2.40.1



Re: [PATCH] gitlog-to-changelog: Make output reproducible.

2024-04-12 Thread Paul Eggert

On 2024-04-12 10:54, Simon Josefsson via Gnulib discussion list wrote:

I'll try to come up with a fix.


Emacs has had the tradition of using UTC for ChangeLog dates, so please 
support that as well, as an option. This Emacs tradition dates back to 
the RCS days, as RCS supports only UTC timestamps for commits. Because 
UTC commit dates in ChangeLogs are sorted numerically, this lessens 
confusion for newbie ChangeLog readers.


Although using UTC can be offputtinmg to a somewhat more expert reader 
who prefers dates to use the committer's UTC offset, ChangeLog format is 
not obvious anyway when the line contains the *committer's* date but the 
*author's* name. Projects like Emacs can reasonably prefer the confusion 
of using UTC, to the confusion of dates that seem to be out of order.




Re: ./bootstrap --gnulib-srcdir and GNULIB_REVISION

2024-04-10 Thread Paul Eggert
My quick reaction is that you've identified two bugs. --gnulib-srcdir 
should only read from that directory, and GNULIB_REVISION should work in 
bootstrap.conf.




Re: autoreconf --force seemingly does not forcibly update everything

2024-04-10 Thread Paul Eggert

On 4/10/24 13:36, Simon Josefsson via Gnulib discussion list wrote:

Is bootstrap intended to be reliable from within a tarball?  I thought
the bootstrap script was not included in tarballs because it wasn't
designed to be ran that way, and the way it is designed may not give
expected results.


It's pretty routinely distributed, I expect under the theory that we're 
being transparent about what sources we use to generate the tarball.


Whether it works from a tarball depends on one's definition of "works". 
Certainly more expertise and tools are needed to bootstrap than merely 
to configure + make.




  1   2   3   4   5   6   7   8   9   10   >