[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10305: coreutils-8.14, "rm -r" fails with EBADF
From: |
Paul Eggert |
Subject: |
bug#10305: coreutils-8.14, "rm -r" fails with EBADF |
Date: |
Wed, 20 Feb 2013 00:07:57 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 |
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