Re: fts: Document this module
On Thu, Jan 19, 2023 at 7:05 PM Paul Eggert wrote: > > On 1/19/23 15:41, Bruno Haible wrote: > > Jim or Paul, what should we state > > — either in the 'fts' module description, or in the .texi documentation? > > The quick thing is to say in both that the description/documentation is > incomplete, and that people need to read the source code. > > Jim may be able to fill in a bit here, since I think he wrote most of > that stuff. (I haven't checked this though; sorry, I'm a bit crunched > for time today.) Thanks for caring/documenting. Here's a quick summary (for more detail, see the comments in fts_.h). This started when I found glibc's fts was insufficiently robust to meet GNU rm's needs (rm was merely the first user; now, many others use it): - O(N^2) behavior in the number of file name components due to cycle detection - max hierarchy depth was 64k due to type of fts_level being a "short" - subject to O(N^2) effects for directories with many entries (poor locality of reference, for which the fix was to process entries in sorted-inode order (per a heuristic), delaying any "stat" until operating on the entry) Re fts's cycle detection: - contrast glibc's O(depth) time algorithm vs our O(1) implementation - our cheap-but-lazy O(1)-memory approach is ok for most applications, but - there's an optional, slightly more costly detect-ASAP approach required for du (uses O(max-depth-of-hierarchy) memory) Fixing those things required ABI changes and nontrivial redesign.
Re: Making _Noreturn a no-op in < Clang 16?
> On 20 Jan 2023, at 03:40, Paul Eggert wrote: > > On 1/19/23 13:30, Sam James wrote: >> Right, I just meant that we don't tend to care about quieting warnings with >> older compilers, >> and it's not useful from a static analysis perspective here either given >> that older Clangs can't be trusted. >> It is of course useful as an attribute in general. I don't think either of >> these things are really >> a downside to committing the workaround here. If we get folks who get build >> failures with extra warnings >> enabled, we can tell them to upgrade their compiler. > > But clang 16 isn't out yet, so we can't reasonably tell people to upgrade. > > And even if it clang 16 were out, I can't reasonably tell all Emacs > developers to switch to it right away. Many of them are using Apple's > compiler and will upgrade whenever. Plain './configure; make' on a > bleeding-edge Emacs built from Git with Clang 15 would generate 270 false > alarms if we simply did "#define _Noreturn /**/", and I expect many Emacs > developers would be annoyed by that (or would stop paying attention to any > correct diagnostics mixed in with the flood of false positives). > I take your point and it's fair enough. Thanks for hashing it out with me. > With that in mind, how about the attached Gnulib patch? (I haven't installed > it.) The basic idea is to "#define _Noreturn /**/" on buggy clangs if a > cautious builder compiles with > -D_GL_WORK_AROUND_LLVM_BUG_5979.<0001-snippet-_Noreturn-work-around-Clang-_Noreturn-bug.patch> If it's not too much of a hassle, this works for me, because at least we advertise the problem a bit, and we can tell distros to set -D_... if they're stuck on older Clang for a bit. Cheers Paul. Best, sam signature.asc Description: Message signed with OpenPGP
Re: Making _Noreturn a no-op in < Clang 16?
On 1/19/23 13:30, Sam James wrote: Right, I just meant that we don't tend to care about quieting warnings with older compilers, and it's not useful from a static analysis perspective here either given that older Clangs can't be trusted. It is of course useful as an attribute in general. I don't think either of these things are really a downside to committing the workaround here. If we get folks who get build failures with extra warnings enabled, we can tell them to upgrade their compiler. But clang 16 isn't out yet, so we can't reasonably tell people to upgrade. And even if it clang 16 were out, I can't reasonably tell all Emacs developers to switch to it right away. Many of them are using Apple's compiler and will upgrade whenever. Plain './configure; make' on a bleeding-edge Emacs built from Git with Clang 15 would generate 270 false alarms if we simply did "#define _Noreturn /**/", and I expect many Emacs developers would be annoyed by that (or would stop paying attention to any correct diagnostics mixed in with the flood of false positives). With that in mind, how about the attached Gnulib patch? (I haven't installed it.) The basic idea is to "#define _Noreturn /**/" on buggy clangs if a cautious builder compiles with -D_GL_WORK_AROUND_LLVM_BUG_5979.From 9d3f533586e07eba2c094501c83a22b561cc755c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 19 Jan 2023 19:39:03 -0800 Subject: [PROPOSED] snippet/_Noreturn: work around Clang _Noreturn bug MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This is a bigger-hammer workaround for the clang _Noreturn issue fix for dfa.c on 2023-01-01. Unfortunately, it causes 270 -Wreturn-type and -Wsometimes-uninitialized warnings when building bleeding-edge GNU Emacs from Git on Fedora 37 with plain ‘./configure && make’. So the workaround is enabled only if you compile with -D_GL_WORK_AROUND_LLVM_BUG_59792. * lib/_Noreturn.h (_Noreturn): * m4/gnulib-common.m4 (gl_COMMON_BODY): #define _Noreturn to be empty if it is Clang 15 or earlier, and if _GL_WORK_AROUND_LLVM_BUG_59792 is defined. --- ChangeLog | 14 ++ lib/_Noreturn.h | 5 + m4/gnulib-common.m4 | 5 + 3 files changed, 24 insertions(+) diff --git a/ChangeLog b/ChangeLog index ddd9e2b1aa..5d0c8f7cd7 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,17 @@ +2023-01-19 Paul Eggert + + snippet/_Noreturn: work around Clang _Noreturn bug + This is a bigger-hammer workaround for the clang _Noreturn issue + fix for dfa.c on 2023-01-01. Unfortunately, it causes 270 + -Wreturn-type and -Wsometimes-uninitialized warnings when building + bleeding-edge GNU Emacs from Git on Fedora 37 with plain + ‘./configure && make’. So the workaround is enabled only if you + compile with -D_GL_WORK_AROUND_LLVM_BUG_59792. + * lib/_Noreturn.h (_Noreturn): + * m4/gnulib-common.m4 (gl_COMMON_BODY): + #define _Noreturn to be empty if it is Clang 15 or earlier, + and if _GL_WORK_AROUND_LLVM_BUG_59792 is defined. + 2023-01-19 Bruno Haible Fix warnings for functions introduced in Android API level 34. diff --git a/lib/_Noreturn.h b/lib/_Noreturn.h index fa15b1b25e..6ecea98b54 100644 --- a/lib/_Noreturn.h +++ b/lib/_Noreturn.h @@ -26,6 +26,11 @@ AIX system header files and several gnulib header files use precisely this syntax with 'extern'. */ # define _Noreturn [[noreturn]] +# elif (defined __clang__ && __clang_major__ < 16 \ +&& defined _GL_WORK_AROUND_LLVM_BUG_59792) + /* Compile with -D_GL_WORK_AROUND_LLVM_BUG_59792 to work around + that rare LLVM bug, though you may get many false-alarm warnings. */ +# define _Noreturn # elif ((!defined __cplusplus || defined __clang__) \ && (201112 <= (defined __STDC_VERSION__ ? __STDC_VERSION__ : 0) \ || (!defined __STRICT_ANSI__ \ diff --git a/m4/gnulib-common.m4 b/m4/gnulib-common.m4 index 2db3376b01..fa814222ce 100644 --- a/m4/gnulib-common.m4 +++ b/m4/gnulib-common.m4 @@ -38,6 +38,11 @@ AC_DEFUN([gl_COMMON_BODY], [ AIX system header files and several gnulib header files use precisely this syntax with 'extern'. */ # define _Noreturn [[noreturn]] +# elif (defined __clang__ && __clang_major__ < 16 \ +&& defined _GL_WORK_AROUND_LLVM_BUG_59792) + /* Compile with -D_GL_WORK_AROUND_LLVM_BUG_59792 to work around + that rare LLVM bug, though you may get many false-alarm warnings. */ +# define _Noreturn # elif ((!defined __cplusplus || defined __clang__) \ && (201112 <= (defined __STDC_VERSION__ ? __STDC_VERSION__ : 0) \ || (!defined __STRICT_ANSI__ \ -- 2.39.0
Re: fts: Document this module
On 1/19/23 15:41, Bruno Haible wrote: Jim or Paul, what should we state — either in the 'fts' module description, or in the .texi documentation? The quick thing is to say in both that the description/documentation is incomplete, and that people need to read the source code. Jim may be able to fill in a bit here, since I think he wrote most of that stuff. (I haven't checked this though; sorry, I'm a bit crunched for time today.)
Re: fts: Document this module
> The gnulib fts is different from glibc API, and they can return > different results when called the same way. See end of earlier thread > here: > > https://lists.gnu.org/archive/html/bug-gnulib/2021-07/msg00070.html Thanks for the heads-up, Simon. > I'm not sure what could be done. Perhaps adding a sentence to the > gnulib documentation stating that the gnulib fts is not a drop-in > replacement for missing fts functionality but a separate implementation > with different behaviour. I'm not sure about what to write either. Jim or Paul, what should we state — either in the 'fts' module description, or in the .texi documentation? Bruno
Re: fts: Document this module
Bruno Haible writes: > The 'fts' module was not documented in the documentation, so far. The gnulib fts is different from glibc API, and they can return different results when called the same way. See end of earlier thread here: https://lists.gnu.org/archive/html/bug-gnulib/2021-07/msg00070.html I'm not sure what could be done. Perhaps adding a sentence to the gnulib documentation stating that the gnulib fts is not a drop-in replacement for missing fts functionality but a separate implementation with different behaviour. /Simon signature.asc Description: PGP signature
Re: Making _Noreturn a no-op in < Clang 16?
> On 19 Jan 2023, at 21:20, Paul Eggert wrote:
>
> On 1/19/23 12:44, Sam James wrote:
>> _Noreturn is pretty much just an optimisation (and I'm not convinced that
>> it's _needed_ in a lot of cases, rather just a useful hint).
>
> _Noreturn is not just an optimization: it's also useful for static checking.
> For example:
>
> int
> f (int x)
> {
> if (x < INT_MAX)
> return x + 1;
> error (1, 0, "x is too large");
> }
>
> Since error is _Noreturn the compiler knows not to warn that F might return
> garbage. It's useful to suppress false alarms, even when Clang is the
> compiler.
>
Right, I just meant that we don't tend to care about quieting warnings with
older compilers,
and it's not useful from a static analysis perspective here either given that
older Clangs can't be trusted.
It is of course useful as an attribute in general. I don't think either of
these things are really
a downside to committing the workaround here. If we get folks who get build
failures with extra warnings
enabled, we can tell them to upgrade their compiler.
signature.asc
Description: Message signed with OpenPGP
Re: Making _Noreturn a no-op in < Clang 16?
On 1/19/23 12:44, Sam James wrote:
_Noreturn is pretty much just an optimisation (and I'm not convinced
that it's _needed_ in a lot of cases, rather just a useful hint).
_Noreturn is not just an optimization: it's also useful for static
checking. For example:
int
f (int x)
{
if (x < INT_MAX)
return x + 1;
error (1, 0, "x is too large");
}
Since error is _Noreturn the compiler knows not to warn that F might
return garbage. It's useful to suppress false alarms, even when Clang is
the compiler.
> Is there any precedent wrt
> handling miscompilations for actively supported compilers in gnulib
and such?
We've run into them before; I don't know of a list of instances.
Generally speaking if the workaround is easy and harmless we can install
it, otherwise we tell users to get a working compiler.
Re: More Android patches
I wrote: > In a second step, I looked for occurrences to AC_CHECK_FUNC[S] > or AC_CHECK_FUNCS_ONCE of these symbols. E.g. > for s in `cat in-8.txt`; do grep -rw "$s" m4 modules | grep CHECK_FUNC; > echo ; done > and replaced these with gl_CHECK_FUNCS_ANDROID invocations. Having finished and regression-tested these changes, here's what I committed. >From 6c4ed27dce71dc788efa6ef6430849d4bb5bf39d Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Thu, 19 Jan 2023 21:55:10 +0100 Subject: [PATCH 01/15] Fix warnings for functions introduced in Android API level 8. * m4/ttyname_r.m4 (gl_FUNC_TTYNAME_R): Test for ttyname_r using gl_CHECK_FUNCS_ANDROID instead of AC_CHECK_FUNCS. --- ChangeLog | 6 ++ m4/ttyname_r.m4 | 4 ++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 5cbe84d1b1..72b816f990 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2023-01-19 Bruno Haible + + Fix warnings for functions introduced in Android API level 8. + * m4/ttyname_r.m4 (gl_FUNC_TTYNAME_R): Test for ttyname_r using + gl_CHECK_FUNCS_ANDROID instead of AC_CHECK_FUNCS. + 2023-01-19 Bruno Haible fts: Document this module. diff --git a/m4/ttyname_r.m4 b/m4/ttyname_r.m4 index 3f027da45a..4a76155469 100644 --- a/m4/ttyname_r.m4 +++ b/m4/ttyname_r.m4 @@ -1,4 +1,4 @@ -# ttyname_r.m4 serial 11 +# ttyname_r.m4 serial 12 dnl Copyright (C) 2010-2023 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -17,7 +17,7 @@ AC_DEFUN([gl_FUNC_TTYNAME_R], HAVE_DECL_TTYNAME_R=0 fi - AC_CHECK_FUNCS([ttyname_r]) + gl_CHECK_FUNCS_ANDROID([ttyname_r], [[#include ]]) if test $ac_cv_func_ttyname_r = no; then HAVE_TTYNAME_R=0 else -- 2.34.1 >From 39bfcd72a808c3091b39d797c9576f26c197c3df Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Thu, 19 Jan 2023 21:55:13 +0100 Subject: [PATCH 02/15] Fix warnings for functions introduced in Android API level 9. * m4/pipe2.m4 (gl_FUNC_PIPE2): Test for pipe2 using gl_CHECK_FUNCS_ANDROID instead of AC_CHECK_FUNCS_ONCE. * m4/fdatasync.m4 (gl_FUNC_FDATASYNC): Update comments. --- ChangeLog | 7 +++ m4/fdatasync.m4 | 3 ++- m4/pipe2.m4 | 4 ++-- 3 files changed, 11 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index 72b816f990..26c07501b3 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2023-01-19 Bruno Haible + + Fix warnings for functions introduced in Android API level 9. + * m4/pipe2.m4 (gl_FUNC_PIPE2): Test for pipe2 using + gl_CHECK_FUNCS_ANDROID instead of AC_CHECK_FUNCS_ONCE. + * m4/fdatasync.m4 (gl_FUNC_FDATASYNC): Update comments. + 2023-01-19 Bruno Haible Fix warnings for functions introduced in Android API level 8. diff --git a/m4/fdatasync.m4 b/m4/fdatasync.m4 index 8c5cc4fdaf..201d7ffb27 100644 --- a/m4/fdatasync.m4 +++ b/m4/fdatasync.m4 @@ -1,4 +1,4 @@ -# fdatasync.m4 serial 7 +# fdatasync.m4 serial 8 dnl Copyright (C) 2008-2023 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -17,6 +17,7 @@ AC_DEFUN([gl_FUNC_FDATASYNC], if test $ac_cv_have_decl_fdatasync = no; then HAVE_DECL_FDATASYNC=0 dnl Mac OS X 10.7 has fdatasync but does not declare it. +dnl Likewise Android with API level < 9. Cf. gl_CHECK_FUNCS_ANDROID. AC_CHECK_FUNCS([fdatasync]) if test $ac_cv_func_fdatasync = no; then HAVE_FDATASYNC=0 diff --git a/m4/pipe2.m4 b/m4/pipe2.m4 index 501f3a4303..c7ec02e873 100644 --- a/m4/pipe2.m4 +++ b/m4/pipe2.m4 @@ -1,4 +1,4 @@ -# pipe2.m4 serial 2 +# pipe2.m4 serial 3 dnl Copyright (C) 2009-2023 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -11,7 +11,7 @@ AC_DEFUN([gl_FUNC_PIPE2], dnl Persuade glibc to declare pipe2(). AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS]) - AC_CHECK_FUNCS_ONCE([pipe2]) + gl_CHECK_FUNCS_ANDROID([pipe2], [[#include ]]) if test $ac_cv_func_pipe2 != yes; then HAVE_PIPE2=0 fi -- 2.34.1 >From 430cd900f19b62994c8cc1b6f1b560b4aed94025 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Thu, 19 Jan 2023 21:55:15 +0100 Subject: [PATCH 03/15] Fix warnings for functions introduced in Android API level 12. Reported by Po Lu . * m4/ftruncate.m4 (gl_FUNC_FTRUNCATE): Test for ftruncate using gl_CHECK_FUNCS_ANDROID instead of AC_CHECK_FUNCS_ONCE. * m4/glob.m4 (gl_PREREQ_GLOB): Test for getpwnam_r using gl_CHECK_FUNCS_ANDROID instead of AC_CHECK_FUNCS_ONCE. * m4/nproc.m4 (gl_PREREQ_NPROC): Test for sched_getaffinity using gl_CHECK_FUNCS_ANDROID instead of AC_CHECK_FUNCS. * m4/pread.m4 (gl_FUNC_PREAD): Test for pread using gl_CHECK_FUNCS_ANDROID instead of AC_CHECK_FUNCS_ONCE. * m4/pwrite.m4 (gl_FUNC_PWRITE): Test for pwrite using gl_CHECK_FUNCS_ANDROID instead of
Re: Making _Noreturn a no-op in < Clang 16?
> On 19 Jan 2023, at 04:17, Paul Eggert wrote: > > The problem we found in Gawk was that this sort of function call: > >(b ? f : g) (x) > > is mishandled by Clang < 16 when one function is _Noreturn and the other > isn't, in that Clang mistakenly treats the call as if both functions are > _Noreturn. > > I expect this sort of issue to be reasonably rare in practical C code, as > most people don't write code like the above, and when they do then typically > F is _Noreturn if and only if G is also _Noreturn. So I've held off on doing > the more-drastic "#define _Noreturn /*empty*/" for Clang < 16 in Gnulib, as > my guess has been that the advantages of enabling _Noreturn on Clang < 16 are > greater than the disadvantages given the rarity of situations like the above. > I don't have any sort of statistics on this either. _Noreturn is pretty much just an optimisation (and I'm not convinced that it's _needed_ in a lot of cases, rather just a useful hint). I'd rather a correct result than a quicker one. But then again, you could argue that given nobody noticed for at least 13 years (including with several Linux distros building gawk with Clang), it's not a big deal in the wild. (err() is noreturn anyway so I'd expect the compiler to be able to deduce it.) Up to you. I think the conservative option is to do it, but if you feel uncertain, we can probably just leave the matter. Is there any precedent wrt handling miscompilations for actively supported compilers in gnulib and such? signature.asc Description: Message signed with OpenPGP
fts: Document this module
The 'fts' module was not documented in the documentation, so far.
2023-01-19 Bruno Haible
fts: Document this module.
* doc/glibc-headers/fts.texi: Mention the 'fts' module.
* doc/glibc-functions/fts_children.texi: Likewise.
* doc/glibc-functions/fts_close.texi: Likewise.
* doc/glibc-functions/fts_open.texi: Likewise.
* doc/glibc-functions/fts_read.texi: Likewise.
* doc/glibc-functions/fts_set.texi: Likewise.
diff --git a/doc/glibc-functions/fts_children.texi
b/doc/glibc-functions/fts_children.texi
index 12ec251f31..0a43e2621f 100644
--- a/doc/glibc-functions/fts_children.texi
+++ b/doc/glibc-functions/fts_children.texi
@@ -4,18 +4,18 @@
Documentation:@*
@uref{https://www.kernel.org/doc/man-pages/online/pages/man3/fts_children.3.html,,man
fts_children}
-Gnulib module: ---
+Gnulib module: fts
Portability problems fixed by Gnulib:
@itemize
+@item
+This function is missing on some platforms:
+AIX 5.1, HP-UX 11, IRIX 6.5, Solaris 11.3, mingw, MSVC 14.
@end itemize
Portability problems not fixed by Gnulib:
@itemize
@item
-This function is missing on some platforms:
-AIX 5.1, HP-UX 11, IRIX 6.5, Solaris 11.3, mingw, MSVC 14.
-@item
On platforms where @code{off_t} is a 32-bit type, this function may not
correctly report the size of files or block devices larger than 2 GB and
may not work correctly on huge directories larger than 2 GB@. Also, on
diff --git a/doc/glibc-functions/fts_close.texi
b/doc/glibc-functions/fts_close.texi
index ff5bebe84b..6cd4439fbe 100644
--- a/doc/glibc-functions/fts_close.texi
+++ b/doc/glibc-functions/fts_close.texi
@@ -4,15 +4,15 @@
Documentation:@*
@uref{https://www.kernel.org/doc/man-pages/online/pages/man3/fts_close.3.html,,man
fts_close}
-Gnulib module: ---
+Gnulib module: fts
Portability problems fixed by Gnulib:
@itemize
+@item
+This function is missing on some platforms:
+AIX 5.1, HP-UX 11, IRIX 6.5, Solaris 11.3, mingw, MSVC 14.
@end itemize
Portability problems not fixed by Gnulib:
@itemize
-@item
-This function is missing on some platforms:
-AIX 5.1, HP-UX 11, IRIX 6.5, Solaris 11.3, mingw, MSVC 14.
@end itemize
diff --git a/doc/glibc-functions/fts_open.texi
b/doc/glibc-functions/fts_open.texi
index 9142e288bf..4d1ce289d5 100644
--- a/doc/glibc-functions/fts_open.texi
+++ b/doc/glibc-functions/fts_open.texi
@@ -4,15 +4,15 @@
Documentation:@*
@uref{https://www.kernel.org/doc/man-pages/online/pages/man3/fts_open.3.html,,man
fts_open}
-Gnulib module: ---
+Gnulib module: fts
Portability problems fixed by Gnulib:
@itemize
+@item
+This function is missing on some platforms:
+AIX 5.1, HP-UX 11, IRIX 6.5, Solaris 11.3, mingw, MSVC 14.
@end itemize
Portability problems not fixed by Gnulib:
@itemize
-@item
-This function is missing on some platforms:
-AIX 5.1, HP-UX 11, IRIX 6.5, Solaris 11.3, mingw, MSVC 14.
@end itemize
diff --git a/doc/glibc-functions/fts_read.texi
b/doc/glibc-functions/fts_read.texi
index a0faa77d7f..7737d096cc 100644
--- a/doc/glibc-functions/fts_read.texi
+++ b/doc/glibc-functions/fts_read.texi
@@ -4,18 +4,18 @@
Documentation:@*
@uref{https://www.kernel.org/doc/man-pages/online/pages/man3/fts_read.3.html,,man
fts_read}
-Gnulib module: ---
+Gnulib module: fts
Portability problems fixed by Gnulib:
@itemize
+@item
+This function is missing on some platforms:
+AIX 5.1, HP-UX 11, IRIX 6.5, Solaris 11.3, mingw, MSVC 14.
@end itemize
Portability problems not fixed by Gnulib:
@itemize
@item
-This function is missing on some platforms:
-AIX 5.1, HP-UX 11, IRIX 6.5, Solaris 11.3, mingw, MSVC 14.
-@item
On platforms where @code{off_t} is a 32-bit type, this function may not
correctly report the size of files or block devices larger than 2 GB and
may not work correctly on huge directories larger than 2 GB@. Also, on
diff --git a/doc/glibc-functions/fts_set.texi b/doc/glibc-functions/fts_set.texi
index 47f645401e..297ceb476f 100644
--- a/doc/glibc-functions/fts_set.texi
+++ b/doc/glibc-functions/fts_set.texi
@@ -4,15 +4,15 @@
Documentation:@*
@uref{https://www.kernel.org/doc/man-pages/online/pages/man3/fts_set.3.html,,man
fts_set}
-Gnulib module: ---
+Gnulib module: fts
Portability problems fixed by Gnulib:
@itemize
+@item
+This function is missing on some platforms:
+AIX 5.1, HP-UX 11, IRIX 6.5, Solaris 11.3, mingw, MSVC 14.
@end itemize
Portability problems not fixed by Gnulib:
@itemize
-@item
-This function is missing on some platforms:
-AIX 5.1, HP-UX 11, IRIX 6.5, Solaris 11.3, mingw, MSVC 14.
@end itemize
diff --git a/doc/glibc-headers/fts.texi b/doc/glibc-headers/fts.texi
index 4fe6714e60..f725d8cf1c 100644
--- a/doc/glibc-headers/fts.texi
+++ b/doc/glibc-headers/fts.texi
@@ -11,15 +11,15 @@ Documentation:
@uref{https://www.kernel.org/doc/man-pages/online/pages/man3/fts.3.html,,man
fts}.
@end itemize
-Gnulib module: ---
+Gnulib module: fts
Portability problems fixed by Gnulib:
@itemize
+@item
+This
Re: API levels and functions on Android
Paul Eggert wrote: > > Defining REPLACE_GLOB=1 despite HAVE_GLOB=0 will be the way to make Gnulib > > define 'rpl_glob' instead of 'glob', so that there is no conflict with > > libc.so. > > > > I still need to work out the details how this would/will work. So as to > > do things correctly on Android, while OTOH not adding lots of configure > > tests > > for the other platforms... > > Thanks for looking into this. > > On Android, should we always define REPLACE_WHATEVER when 'whatever' > doesn't exist, at least for all the REPLACE_WHATEVER instances that > currently exist in Gnulib? After all, 'whatever' might exist in some > future Android version. I think this would be overkill. Remember, for debuggability, when Gnulib defines a function 'foo', we want gdb to know it by the name 'foo', if there is no imperative to name it differently. The two known imperatives are - call it 'rpl_foo', to avoid a clash with libc, - when shipping a shared library libgaga, call it 'libgaga_foo' or 'gaga_foo', to avoid a clash with other shared libraries. If none of these two imperatives apply, the name 'foo' without any prefix is the natural choice. > Would it make sense to wait until you've worked out the details, before > installing patches like the REPLACE_UTIMENSAT=1 patch? Yes, definitely. Bruno
