qcopy-acl: Fix copying of ACLs on CentOS 7

2024-07-15 Thread Bruno Haible
The CI of GNU sed shows a test failure of the Gnulib 'acl' tests on CentOS 7
[1]. Namely:

  FAIL: test-copy-acl.sh
  FAIL: test-copy-acl-1.sh
  FAIL: test-copy-acl-2.sh

It can be reproduced like this:

  $ echo 'Simple contents' > tmpfile0
  $ echo 'Simple contents' > tmpfile2
  $ chmod 600 tmpfile0
  $ setfacl -m user:1:1 tmpfile0
  $ getfacl tmpfile0
  user::rw-
  user:bin:--x
  group::---
  mask::--x
  other::---
  $ ./test-copy-acl tmpfile0 tmpfile2
  $ getfacl tmpfile2
  user::rw-
  group::--x
  other::---

The tests passed in older gnulib:

  2018-01-01 PASS
  2020-01-01 PASS
  2023-01-01 PASS
  2023-04-12 FAIL
  2024-01-01 FAIL

So, it must have been a regression from the 2023-01-12 commit.

Debugging it, I see two invocations of is_attr_permissions:

  is_attr_permissions("security.selinux",NULL) => 0
  is_attr_permissions("system.posix_acl_access",NULL) => 0

It is the latter which causes libattr to copy no attributes.

The patch below fixes it.

[1] https://github.com/gnu-sed/ci-check/actions/runs/9935643107


2024-07-15  Bruno Haible  

qcopy-acl: Fix copying of ACLs on CentOS 7 (regression 2023-01-12).
* lib/qcopy-acl.c: Include , .
(XATTR_NAME_NFSV4_ACL, XATTR_NAME_POSIX_ACL_ACCESS,
XATTR_NAME_POSIX_ACL_DEFAULT): New macros, from file-has-acl.c.
(is_attr_permissions): Test for these names explicitly.
* m4/acl.m4 (gl_QCOPY_ACL): New macro.
* modules/qcopy-acl (Files): Add m4/acl.m4.
(configure.ac): Invoke gl_QCOPY_ACL.

diff --git a/lib/qcopy-acl.c b/lib/qcopy-acl.c
index dfc39cead0..877f42588b 100644
--- a/lib/qcopy-acl.c
+++ b/lib/qcopy-acl.c
@@ -26,6 +26,20 @@
 #if USE_XATTR
 
 # include 
+# include 
+
+# if HAVE_LINUX_XATTR_H
+#  include 
+# endif
+# ifndef XATTR_NAME_NFSV4_ACL
+#  define XATTR_NAME_NFSV4_ACL "system.nfs4_acl"
+# endif
+# ifndef XATTR_NAME_POSIX_ACL_ACCESS
+#  define XATTR_NAME_POSIX_ACL_ACCESS "system.posix_acl_access"
+# endif
+# ifndef XATTR_NAME_POSIX_ACL_DEFAULT
+#  define XATTR_NAME_POSIX_ACL_DEFAULT "system.posix_acl_default"
+# endif
 
 /* Returns 1 if NAME is the name of an extended attribute that is related
to permissions, i.e. ACLs.  Returns 0 otherwise.  */
@@ -33,7 +47,12 @@
 static int
 is_attr_permissions (const char *name, struct error_context *ctx)
 {
-  return attr_copy_action (name, ctx) == ATTR_ACTION_PERMISSIONS;
+  /* We need to explicitly test for the known extended attribute names,
+ because at least on CentOS 7, attr_copy_action does not do it.  */
+  return strcmp (name, XATTR_NAME_POSIX_ACL_ACCESS) == 0
+ || strcmp (name, XATTR_NAME_POSIX_ACL_DEFAULT) == 0
+ || strcmp (name, XATTR_NAME_NFSV4_ACL) == 0
+ || attr_copy_action (name, ctx) == ATTR_ACTION_PERMISSIONS;
 }
 
 #endif  /* USE_XATTR */
diff --git a/m4/acl.m4 b/m4/acl.m4
index c7b6ec2b14..be88f1b831 100644
--- a/m4/acl.m4
+++ b/m4/acl.m4
@@ -1,5 +1,5 @@
 # acl.m4
-# serial 30
+# serial 31
 dnl Copyright (C) 2002, 2004-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,
@@ -178,13 +178,14 @@ AC_DEFUN([gl_ACL_GET_FILE]
   AS_IF([test "$gl_cv_func_working_acl_get_file" != no], [$1], [$2])
 ])
 
-# On GNU/Linux, testing if a file has an acl can be done with the
-# listxattr and getxattr syscalls, which don't require linking
-# against additional libraries.  Assume this works if linux/attr.h
-# and listxattr are present.
+# Prerequisites of module file-has-acl.
 AC_DEFUN([gl_FILE_HAS_ACL],
 [
   AC_REQUIRE([gl_FUNC_ACL_ARG])
+  # On GNU/Linux, testing if a file has an acl can be done with the
+  # listxattr and getxattr syscalls, which don't require linking
+  # against additional libraries.  Assume this works if linux/attr.h
+  # and listxattr are present.
   AC_CHECK_HEADERS_ONCE([linux/xattr.h])
   AC_CHECK_FUNCS_ONCE([listxattr])
   FILE_HAS_ACL_LIB=
@@ -198,3 +199,17 @@ AC_DEFUN([gl_FILE_HAS_ACL]
FILE_HAS_ACL_LIB=$LIB_ACL])
   AC_SUBST([FILE_HAS_ACL_LIB])
 ])
+
+# Prerequisites of module qcopy-acl.
+AC_DEFUN([gl_QCOPY_ACL],
+[
+  AC_REQUIRE([gl_FUNC_ACL])
+  AC_CHECK_HEADERS_ONCE([linux/xattr.h])
+  gl_FUNC_XATTR
+  if test "$use_xattr" = yes; then
+QCOPY_ACL_LIB="$LIB_XATTR"
+  else
+QCOPY_ACL_LIB="$LIB_ACL"
+  fi
+  AC_SUBST([QCOPY_ACL_LIB])
+])
diff --git a/modules/qcopy-acl b/modules/qcopy-acl
index b89d8ecab6..e692a28625 100644
--- a/modules/qcopy-acl
+++ b/modules/qcopy-acl
@@ -3,20 +3,14 @@ Copy access control list from one file to another.  
(Unportable.)
 
 Files:
 lib/qcopy-acl.c
+m4/acl.m4
 m4/xattr.m4
 
 Depends-on:
 acl-permissions [test "$use_xattr" != yes]
 
 configure.ac:
-gl_FUNC_XATTR
-AC_REQUIRE([gl_FUNC_ACL])
-if test "$use_xattr" = yes; then
-  QCOPY_ACL_LIB="$LIB_XATTR"
-else
-  QCOPY_ACL_LIB="$LIB_ACL"
-fi
-AC_SUBST([QCOPY_ACL_LIB])
+gl_QCOPY_ACL
 
 Makefile.am:
 lib_SOURCES += qcopy-acl.c






manywarnings: Don't enable -Wsystem-headers

2024-07-15 Thread Bruno Haible
GNU gettext makes use of the 'manywarnings' module.

In a build on macOS 12,13,14, the output of "make" contains more than
11 warnings of type -Wnullability-completeness, that go away when
-Wsystem-headers is not added on the command line.

In a build on CentOS 7, the output of "make" contains more than 3500
warnings like
  ./time.h:42:3: warning: #include_next is a GCC extension [enabled by default]
that also go away when -Wsystem-headers is not added on the command line.

Since a package author cannot correct warning in "system headers"
(that is, system headers and gnulib header overrides) anyway, this
warning option is pointless also for other packages than GNU gettext.

This patch removes it from the 'manywarnings' module. And likewise for C++.


2024-07-15  Bruno Haible  

manywarnings: Don't enable -Wsystem-headers.
* build-aux/gcc-warning.spec: Add -Wsystem-headers.
* build-aux/g++-warning.spec: Likewise.
* m4/manywarnings.m4 (gl_MANYWARN_ALL_GCC(C)): Don't enable
-Wsystem-headers.
* m4/manywarnings-c++.m4 (gl_MANYWARN_ALL_GCC_CXX_IMPL): Likewise.

diff --git a/build-aux/g++-warning.spec b/build-aux/g++-warning.spec
index 99ef3c8a8d..2235d65e60 100644
--- a/build-aux/g++-warning.spec
+++ b/build-aux/g++-warning.spec
@@ -85,6 +85,7 @@
 -Wswitch-default   
https://lists.gnu.org/r/bug-gnulib/2018-05/msg00179.html
 -Wswitch-enum  FIXME maybe? borderline.  some will 
want this
 -Wsynthdeprecated
+-Wsystem-headers   warns about system headers on macOS and 
#include_next in gnulib headers
 -Wtabs fortran
 -Wtarget-lifetime  fortran
 -Wtraditional-conversion   obsolescent
diff --git a/build-aux/gcc-warning.spec b/build-aux/gcc-warning.spec
index e12fbe776e..53c6bef07d 100644
--- a/build-aux/gcc-warning.spec
+++ b/build-aux/gcc-warning.spec
@@ -348,6 +348,7 @@
 -Wswitch-outside-range default
 -Wswitch-unreachable   default
 -Wsynthdeprecated
+-Wsystem-headers   warns about system headers on macOS and 
#include_next in gnulib headers
 -Wtabs fortran
 -Wtarget-lifetime  fortran
 -Wtautological-compare enabled by -Wall
diff --git a/m4/manywarnings-c++.m4 b/m4/manywarnings-c++.m4
index df190674f9..d8cf54b1cd 100644
--- a/m4/manywarnings-c++.m4
+++ b/m4/manywarnings-c++.m4
@@ -1,5 +1,5 @@
 # manywarnings-c++.m4
-# serial 4
+# serial 5
 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,
@@ -179,7 +179,6 @@ AC_DEFUN([gl_MANYWARN_ALL_GCC_CXX_IMPL]
 -Wswitch \
 -Wswitch-bool \
 -Wsync-nand \
--Wsystem-headers \
 -Wtrampolines \
 -Wtrigraphs \
 -Wtype-limits \
diff --git a/m4/manywarnings.m4 b/m4/manywarnings.m4
index 14bc5041ea..5b0baee205 100644
--- a/m4/manywarnings.m4
+++ b/m4/manywarnings.m4
@@ -1,5 +1,5 @@
 # manywarnings.m4
-# serial 26
+# serial 27
 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,
@@ -141,7 +141,6 @@ AC_DEFUN([gl_MANYWARN_ALL_GCC(C
 -Wsuggest-final-methods \
 -Wsuggest-final-types \
 -Wsync-nand \
--Wsystem-headers \
 -Wtrampolines \
 -Wuninitialized \
 -Wunknown-pragmas \






[PATCH] strnlen: port to Android 5.0 (API 21)

2024-07-15 Thread Paul Eggert
This is needed for GNU Emacs, which attempts to port to these
old Android versions.
* m4/strnlen.m4 (AC_FUNC_STRNLEN): Replace if Autoconf 2.72 or
earlier, with code that detects the Android problem with strnlen.
This version works around some further bugs in the test, notably,
misplaced 'volatile' and need for volatile in the AIX 4.3 bug
check too.
---
 ChangeLog| 11 +++
 doc/posix-functions/strnlen.texi | 10 +++
 m4/strnlen.m4| 51 +++-
 3 files changed, 66 insertions(+), 6 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index cb05631a21..08322a3aca 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2024-07-15  Paul Eggert  
+
+   strnlen: port to Android 5.0 (API 21)
+   This is needed for GNU Emacs, which attempts to port to these
+   old Android versions.
+   * m4/strnlen.m4 (AC_FUNC_STRNLEN): Replace if Autoconf 2.72 or
+   earlier, with code that detects the Android problem with strnlen.
+   This version works around some further bugs in the test, notably,
+   misplaced 'volatile' and need for volatile in the AIX 4.3 bug
+   check too.
+
 2024-07-15  Bruno Haible  
 
manywarnings: Don't enable -Wsystem-headers.
diff --git a/doc/posix-functions/strnlen.texi b/doc/posix-functions/strnlen.texi
index e305a41c8c..554ac12213 100644
--- a/doc/posix-functions/strnlen.texi
+++ b/doc/posix-functions/strnlen.texi
@@ -9,15 +9,15 @@ Gnulib module: strnlen
 Portability problems fixed by Gnulib:
 @itemize
 @item
+On some platforms, calls like @code{strnlen (s, maxlen)} can crash if
+@var{s} is null-terminated but address arithmetic overflows
+(i.e., @code{s + maxlen < s}):
+Android 5.0.
+@item
 This function is missing on some platforms:
 Mac OS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, HP-UX 11, Solaris 10, 
mingw.
 @end itemize
 
 Portability problems not fixed by Gnulib:
 @itemize
-@item
-On some platforms, calls like @code{strnlen (s, maxlen)} can crash if
-@var{s} is null-terminated but address arithmetic overflows
-(i.e., @code{s + maxlen < s}):
-Android 5.0.
 @end itemize
diff --git a/m4/strnlen.m4 b/m4/strnlen.m4
index b4d2778524..83a75c0c32 100644
--- a/m4/strnlen.m4
+++ b/m4/strnlen.m4
@@ -1,11 +1,60 @@
 # strnlen.m4
-# serial 14
+# serial 15
 dnl Copyright (C) 2002-2003, 2005-2007, 2009-2024 Free Software Foundation,
 dnl 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.
 
+m4_version_prereq([2.73], [], [
+# Replace AC_FUNC_STRNLEN from Autoconf 2.72 and earlier,
+# which does not check for Android strnlen bugs.
+
+AC_DEFUN([AC_FUNC_STRNLEN],
+[AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS])dnl
+AC_CACHE_CHECK([for working strnlen], [ac_cv_func_strnlen_working],
+[AC_RUN_IFELSE(
+   [AC_LANG_PROGRAM(
+  [AC_INCLUDES_DEFAULT
+   [/* Use pstrnlen to test; 'volatile' prevents the compiler
+   from optimizing the strnlen calls away.  */
+size_t (*volatile pstrnlen) (char const *, size_t) = strnlen;
+char const s[] = "foobar";
+int s_len = sizeof s - 1;
+   ]],
+  [[
+/* AIX 4.3 is buggy: strnlen (S, 1) == 3.  */
+int i;
+for (i = 0; i < s_len + 1; ++i)
+  {
+int expected = i <= s_len ? i : s_len;
+if (pstrnlen (s, i) != expected)
+  return 1;
+  }
+
+/* Android 5.0 (API 21) strnlen ("", SIZE_MAX) incorrectly crashes.  */
+if (pstrnlen ("", -1) != 0)
+  return 1;]])],
+   [ac_cv_func_strnlen_working=yes],
+   [ac_cv_func_strnlen_working=no],
+   [AC_COMPILE_IFELSE(
+  [AC_LANG_PROGRAM([AC_INCLUDES_DEFAULT],
+ [[#if defined _AIX && !defined _AIX51
+#error "AIX pre 5.1 is buggy"
+   #endif
+   #ifdef __ANDROID__
+#include 
+#if __ANDROID_API__ < 22
+ #error "Android API < 22 is buggy"
+#endif
+   #endif
+ ]])],
+  [ac_cv_func_strnlen_working=yes],
+  [ac_cv_func_strnlen_working=no])])])
+test $ac_cv_func_strnlen_working = no && AC_LIBOBJ([strnlen])
+])# AC_FUNC_STRNLEN
+])
+
 AC_DEFUN([gl_FUNC_STRNLEN],
 [
   AC_REQUIRE([gl_STRING_H_DEFAULTS])
-- 
2.43.0




Need for -std=gnu89 or -std=c99 on MacOS

2024-07-15 Thread Jeffrey Walton
Hi Everyone,

In case you are not following the thread, part of GnuPG may need
-std=gnu89 on MacOS. It looks like -std=c99 may also be a workaround.
See the original post[1] and the proposed workaround [2].

[1] 
[2] 

Jeff



Re: Need for -std=gnu89 or -std=c99 on MacOS

2024-07-15 Thread Bruno Haible
Hi Jeffrey,

> In case you are not following the thread, part of GnuPG may need
> -std=gnu89 on MacOS. It looks like -std=c99 may also be a workaround.
> See the original post[1] and the proposed workaround [2].

Is there any impact on Gnulib or on packages that use Gnulib?

AFAICS from a quick look, it's a C++ problem specific to a single platform,
and thus no impact on most GNU packages.

Bruno