Re: Drop Gnulib support for ecvt, fcvt, gcvt, getw, putw?

2022-06-12 Thread Bruno Haible
Paul Eggert wrote:
> The functions ecvt, fcvt, gcvt, getw, putw are no longer in POSIX and 
> the glibc manual pretty much recommends against them. How about if we 
> drop Gnulib support for them? This would speed up 'configure' a bit, 
> among other things. As far as I know nobody uses them.

I think this is a wrong axis of optimization. If we start with these
functions - which may speed up configure by maybe 1% - , next will be
the question about other "rarely" used functions. And in order to
reach an optimization of 20%, you need to remove a *lot* of them. So
many of them, that we'll eventually break packages that use Gnulib
and practically defeat the purpose of porting POSIX to all platforms.

It is more promising IMO to look for other axes of optimizations:
(B) Combine multiple AC_CHECK_DECLS_ONCE or gl_WARN_ON_USE_PREPARE for
different functions into a single compiler invocation, at least
for the common case when GCC is used.
(C) Remove workarounds for specific platforms. I this it by now we can
consider OSF/1, IRIX, and HP-UX as museum systems.

(C) needs to be done with care, because it can easily introduce regressions
on other, still used, systems.

Therefore my favourite would be (B).

Bruno






Re: Drop Gnulib support for ecvt, fcvt, gcvt, getw, putw?

2022-06-12 Thread Jim Meyering
On Sun, Jun 12, 2022, 1:11 PM Paul Eggert  wrote:

> The functions ecvt, fcvt, gcvt, getw, putw are no longer in POSIX and
> the glibc manual pretty much recommends against them. How about if we
> drop Gnulib support for them? This would speed up 'configure' a bit,
> among other things. As far as I know nobody uses them.
>

Sounds good to me.

>


Re: fchmodat.c & lchmod.c - O_PATH & AT_EMPTY_PATH on older kernels

2022-06-12 Thread Paul Eggert

On 6/12/22 08:03, Bruno Haible wrote:


Two tests now fail, that succeeded before yesterday's patch.


Thanks for reporting that. Although I don't have MS-Windows I stared at 
the code a bit and I think I see what might be the problem. I found some 
other potential issues too (basically, I didn't switch from 
fstatat/lstat to readlinkat/readlink often enough so the code is still 
prone to EOVERFLOW problems). I installed the attached further patch, 
which I hope fixes things on MS-Windows and fixes the other issues too.
From d682f8de7f9d384f4cfc482a3ba2960329a8db21 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sun, 12 Jun 2022 13:46:52 -0700
Subject: [PATCH] fchmodat: port better to MS-Windows etc.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

MS-Windows problem reported by Bruno Haible in:
https://lists.gnu.org/r/bug-gnulib/2022-06/msg00041.html
Although I don’t use MS-Windows I see some related fstatat etc.
problems and am trying to fix them with this further patch.
* lib/fchmodat.c (fchmodat):
* lib/lchmod.c (lchmod):
* lib/lchown.c (lchown)
[!HAVE_LCHOWN && HAVE_CHOWN && !CHOWN_MODIFIES_SYMLINK]:
* lib/renameatu.c (renameatu)
[HAVE_RENAME && RENAME_TRAILING_SLASH_SOURCE_BUG]:
Use readlinkat/readlink instead of fstatat/lstat to test merely
whether a string names a symlink, as this avoids problems
with EOVERFLOW.  Also, I hope it works around the MS-Windows
issues that Bruno noted.
* m4/fchmodat.m4 (gl_PREREQ_FCHMODAT):
Check for readlinkat, not lchmod.
* m4/lchmod.m4 (gl_FUNC_LCHMOD): Do not require AC_CANONICAL_HOST
or check for lstat.
(gl_PREREQ_LCHMOD): Check for readlink.
* modules/lchown (Depends-on): Add readlink.  Do not depend on
lstat merely because !HAVE_LCHOWN.
* modules/renameatu (Depends-on): Add fstatat, readlinkat.
---
 ChangeLog | 26 ++
 lib/fchmodat.c| 16 
 lib/lchmod.c  | 17 +++--
 lib/lchown.c  |  4 ++--
 lib/renameatu.c   |  7 ---
 m4/fchmodat.m4|  4 ++--
 m4/lchmod.m4  |  7 +++
 modules/lchown|  3 ++-
 modules/renameatu |  2 ++
 9 files changed, 56 insertions(+), 30 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 2d0340b933..2daa6d8c81 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,29 @@
+2022-06-12  Paul Eggert  
+
+	fchmodat: port better to MS-Windows etc.
+	MS-Windows problem reported by Bruno Haible in:
+	https://lists.gnu.org/r/bug-gnulib/2022-06/msg00041.html
+	Although I don’t use MS-Windows I see some related fstatat etc.
+	problems and am trying to fix them with this further patch.
+	* lib/fchmodat.c (fchmodat):
+	* lib/lchmod.c (lchmod):
+	* lib/lchown.c (lchown)
+	[!HAVE_LCHOWN && HAVE_CHOWN && !CHOWN_MODIFIES_SYMLINK]:
+	* lib/renameatu.c (renameatu)
+	[HAVE_RENAME && RENAME_TRAILING_SLASH_SOURCE_BUG]:
+	Use readlinkat/readlink instead of fstatat/lstat to test merely
+	whether a string names a symlink, as this avoids problems
+	with EOVERFLOW.  Also, I hope it works around the MS-Windows
+	issues that Bruno noted.
+	* m4/fchmodat.m4 (gl_PREREQ_FCHMODAT):
+	Check for readlinkat, not lchmod.
+	* m4/lchmod.m4 (gl_FUNC_LCHMOD): Do not require AC_CANONICAL_HOST
+	or check for lstat.
+	(gl_PREREQ_LCHMOD): Check for readlink.
+	* modules/lchown (Depends-on): Add readlink.  Do not depend on
+	lstat merely because !HAVE_LCHOWN.
+	* modules/renameatu (Depends-on): Add fstatat, readlinkat.
+
 2022-06-12  Bruno Haible  
 
 	doc: Update O_PATH platforms list.
diff --git a/lib/fchmodat.c b/lib/fchmodat.c
index b233c366de..8ed4cb7398 100644
--- a/lib/fchmodat.c
+++ b/lib/fchmodat.c
@@ -83,9 +83,10 @@ fchmodat (int dir, char const *file, mode_t mode, int flags)
 # if NEED_FCHMODAT_NONSYMLINK_FIX
   if (flags == AT_SYMLINK_NOFOLLOW)
 {
-  struct stat st;
+#  if HAVE_READLINKAT
+  char readlink_buf[1];
 
-#  ifdef O_PATH
+#   ifdef O_PATH
   /* Open a file descriptor with O_NOFOLLOW, to make sure we don't
  follow symbolic links, if /proc is mounted.  O_PATH is used to
  avoid a failure if the file is not readable.
@@ -96,7 +97,7 @@ fchmodat (int dir, char const *file, mode_t mode, int flags)
 
   int err;
   char buf[1];
-  if (0 <= readlinkat (fd, "", buf, sizeof buf))
+  if (0 <= readlinkat (fd, "", readlink_buf, sizeof readlink_buf))
 err = EOPNOTSUPP;
   else if (errno == EINVAL)
 {
@@ -113,17 +114,16 @@ fchmodat (int dir, char const *file, mode_t mode, int flags)
   errno = err;
   if (0 <= err)
 return err == 0 ? 0 : -1;
-#  endif
+#   endif
 
   /* O_PATH + /proc is not supported.  */
-  int fstatat_result = fstatat (dir, file, , AT_SYMLINK_NOFOLLOW);
-  if (fstatat_result != 0)
-return fstatat_result;
-  if (S_ISLNK (st.st_mode))
+
+  if (0 <= readlinkat (dir, file, readlink_buf, sizeof readlink_buf))
 {
   errno = EOPNOTSUPP;
   return -1;
 }
+#  endif
 
   /* Fall back on 

Drop Gnulib support for ecvt, fcvt, gcvt, getw, putw?

2022-06-12 Thread Paul Eggert
The functions ecvt, fcvt, gcvt, getw, putw are no longer in POSIX and 
the glibc manual pretty much recommends against them. How about if we 
drop Gnulib support for them? This would speed up 'configure' a bit, 
among other things. As far as I know nobody uses them.





Re: fchmodat.c & lchmod.c - O_PATH & AT_EMPTY_PATH on older kernels

2022-06-12 Thread Bruno Haible
Paul Eggert wrote:
> Also, now that I'm 
> thinking about it, the Gnulib code didn't work if fstatat fails with 
> EOVERFLOW and should be using readlinkat instead. Please try the first 
> attached patch, which I've installed in Gnulib.

The patch works fine on
  - Linux
  - FreeBSD (both with and without O_PATH), NetBSD, OpenBSD,
  - minix 3.3.0
  - macOS 10.x
  - AIX 7.1
  - Solaris 10, 11
  - Cygwin 2.9

But it introduces a regression on native Windows (I tested on mingw).
Two tests now fail, that succeeded before yesterday's patch.

FAIL: test-fchmodat
===

../../gltests/test-fchmodat.c:61: assertion 'errno == ENOTDIR' failed
FAIL test-fchmodat.exe (exit status: 3)

FAIL: test-lchmod
=

../../gltests/test-lchmod.c:47: assertion 'errno == ENOTDIR' failed
FAIL test-lchmod.exe (exit status: 3)

Do you have a test environment for native Windows, or should I look into this?

Bruno






Re: O_PATH

2022-06-12 Thread Bruno Haible
Paul Eggert wrote:
> I also installed the 2nd attached patch which is just a doc update.

The platforms that have O_PATH are:
  - Linux (glibc ≥ 2.14, musl, Android)
  - FreeBSD ≥ 13.1

I'm therefore doing this doc update:


2022-06-12  Bruno Haible  

doc: Update O_PATH platforms list.
* doc/posix-headers/fcntl.texi: Update O_PATH platforms list.

diff --git a/doc/posix-headers/fcntl.texi b/doc/posix-headers/fcntl.texi
index 8be69f4656..dcaba575bb 100644
--- a/doc/posix-headers/fcntl.texi
+++ b/doc/posix-headers/fcntl.texi
@@ -89,8 +89,7 @@ Portability problems not fixed by Gnulib:
 
 @item
 @samp{O_PATH} is not defined on some platforms:
-AIX 7.3, FreeBSD 9.3, IRIX 6.5, macOS 13, mingw, Minix 3.3.0, MSVC 14,
-NetBSD 9.2, OpenBSD 7.1, Solaris 11.4.
+glibc 2.13, macOS 13, FreeBSD 13.0, NetBSD 9.2, OpenBSD 7.1, Minix 3.3.0, AIX 
7.3, HP-UX 11.31, IRIX 6.5, Solaris 11.4, Cygwin 2.9, mingw, MSVC 14.
 
 @item
 @samp{F_SETFD}, @samp{F_GETFL}, @samp{F_SETFL}, @samp{F_GETLK},