Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF

[Paul Eggert]

On 07/19/2012 11:55 PM, V S, Nagendra (Nonstop Filesystems Team) wrote:
> The coreutils config.hin no more defines any of RAW_DECL_* functions, which 
> where present in 8.15.

Thanks, good catch.  I have pushed the following patch to gnulib to fix this;
it should appear in the next coreutils release.  I'll look into the other
NonStop issues later.

---
 ChangeLog             | 13 +++++++++++++
 lib/getcwd.c          |  2 +-
 m4/getcwd-path-max.m4 |  3 +++
 m4/getcwd.m4          |  2 +-
 4 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index a6c50ff..a5b6b13 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,18 @@
 2013-02-19  Paul Eggert  <address@hidden>
 
+       getcwd: support coreutils better
+       Like strtod, getcwd incorrectly referred to HAVE_RAW_DECL_GETCWD,
+       but this might not be correct in coreutils, which disables
+       the raw decl checks.  Problem reported by Nagendra in
+       <http://bugs.gnu.org/10305#192>.
+       * lib/getcwd.c (__getcwd): Do not depend on HAVE_RAW_DECL_GETCWD.
+       * m4/getcwd-path-max.m4 (gl_FUNC_GETCWD_PATH_MAX):
+       Test the getcwd function, not any macro, since getcwd.c wants the
+       function.
+       * m4/getcwd.m4 (gl_FUNC_GETCWD):
+       Don't define HAVE_MINIMALLY_WORKING_GETCWD if the code doesn't
+       compile, as might happen if there's a macro but no function.
+
        strtod: support coreutils better
        * lib/strtod.c (underlying_strtod): Just invoke the underlying strtod.
        HAVE_RAW_DECL_STRTOD might not be correct in coreutils, which
diff --git a/lib/getcwd.c b/lib/getcwd.c
index 4b78138..f31c07e 100644
--- a/lib/getcwd.c
+++ b/lib/getcwd.c
@@ -135,7 +135,7 @@ __getcwd (char *buf, size_t size)
   size_t allocated = size;
   size_t used;
 
-#if HAVE_RAW_DECL_GETCWD && HAVE_MINIMALLY_WORKING_GETCWD
+#if HAVE_MINIMALLY_WORKING_GETCWD
   /* If AT_FDCWD is not defined, the algorithm below is O(N**2) and
      this is much slower than the system getcwd (at least on
      GNU/Linux).  So trust the system getcwd's results unless they
diff --git a/m4/getcwd-path-max.m4 b/m4/getcwd-path-max.m4
index d30e1b3..0b03b66 100644
--- a/m4/getcwd-path-max.m4
+++ b/m4/getcwd-path-max.m4
@@ -52,6 +52,9 @@ AC_DEFUN([gl_FUNC_GETCWD_PATH_MAX],
 # define is_ENAMETOOLONG(x) 0
 #endif
 
+/* Use the getcwd function, not any macro.  */
+#undef getcwd
+
 /* Don't get link errors because mkdir is redefined to rpl_mkdir.  */
 #undef mkdir
 
diff --git a/m4/getcwd.m4 b/m4/getcwd.m4
index 93b3b86..6f91bd9 100644
--- a/m4/getcwd.m4
+++ b/m4/getcwd.m4
@@ -123,7 +123,7 @@ AC_DEFUN([gl_FUNC_GETCWD],
   dnl Define HAVE_MINIMALLY_WORKING_GETCWD and HAVE_PARTLY_WORKING_GETCWD
   dnl if appropriate.
   case "$gl_cv_func_getcwd_path_max" in
-    "no, it has the AIX bug") ;;
+    "no"|"no, it has the AIX bug") ;;
     *)
       AC_DEFINE([HAVE_MINIMALLY_WORKING_GETCWD], [1],
         [Define to 1 if getcwd minimally works, that is, its result can be
-- 
1.7.11.7