Re: vfat lost file problem

2003-08-18 Thread Paul Eggert
Jim Meyering [EMAIL PROTECTED] writes:

 shouldn't the above two references to source_dirname
 be to dest_dirname instead, because only the limits of the
 destination directory are relevant?

Either way should work, because when the code is executed we've
already verified that the source and destination are the same
directory.

It makes the code clearer to use the destination directory, though.

While we're on the subject of same.c, what do you think about the idea
of assuming stdlib.h?  I notice a lot of occurrences of things like
HAVE_DECL_FREE -- is that because you still use hosts that don't have
stdlib.h?  If so, you probably wouldn't like that part of the
following patch:

2003-08-18  Paul Eggert [EMAIL PROTECTED]

* lib/same.c: Include stdlib.h and string.h unconditionally,
as we're now assuming that part of hosted C89.
(free) [!HAVE_DECL_FREE]: Remove decl; no longer needed.
(same_name): Invoke pathconf on destination, not source, as
that's a bit clearer even if they are the same dir.
* m4/same.m4 (gl_SAME): Do not check for stdlib.h or string.h or free.
Check for pathconf.

Index: lib/same.c
===
RCS file: /cvsroot/coreutils/coreutils/lib/same.c,v
retrieving revision 1.11
diff -p -u -r1.11 same.c
--- lib/same.c  18 Aug 2003 07:47:40 -  1.11
+++ lib/same.c  18 Aug 2003 21:38:50 -
@@ -26,9 +26,7 @@
 #ifdef HAVE_UNISTD_H
 # include unistd.h
 #endif
-#if HAVE_STDLIB_H
-# include stdlib.h
-#endif
+#include stdlib.h
 #include sys/types.h
 #include sys/stat.h
 #include ctype.h
@@ -37,11 +35,7 @@
 extern int errno;
 #endif
 
-#if HAVE_STRING_H
-# include string.h
-#else
-# include strings.h
-#endif
+#include string.h
 
 #include limits.h
 #ifndef _POSIX_NAME_MAX
@@ -53,13 +47,6 @@ extern int errno;
 #include error.h
 #include xalloc.h
 
-#ifndef HAVE_DECL_FREE
-this configure-time declaration test was not run
-#endif
-#if !HAVE_DECL_FREE
-void free ();
-#endif
-
 #define MIN(a, b) ((a)  (b) ? (a) : (b))
 
 #define SAME_INODE(Stat_buf_1, Stat_buf_2) \
@@ -121,13 +108,13 @@ same_name (const char *source, const cha
 #if ! _POSIX_NO_TRUNC  HAVE_PATHCONF  defined _PC_NAME_MAX
   if (same  ! identical_basenames)
{
- long name_max = (errno = 0, pathconf (source_dirname, _PC_NAME_MAX));
+ long name_max = (errno = 0, pathconf (dest_dirname, _PC_NAME_MAX));
  if (name_max  0)
{
  if (errno)
{
  /* Shouldn't happen.  */
- error (1, errno, %s, source_dirname);
+ error (1, errno, %s, dest_dirname);
}
  same = false;
}
Index: m4/same.m4
===
RCS file: /cvsroot/coreutils/coreutils/m4/same.m4,v
retrieving revision 1.1
diff -p -u -r1.1 same.m4
--- m4/same.m4  17 Aug 2003 17:58:01 -  1.1
+++ m4/same.m4  18 Aug 2003 21:38:50 -
@@ -1,5 +1,5 @@
-# same.m4 serial 1
-dnl Copyright (C) 2002 Free Software Foundation, Inc.
+# same.m4 serial 2
+dnl Copyright (C) 2002, 2003 Free Software Foundation, Inc.
 dnl This file is free software, distributed under the terms of the GNU
 dnl General Public License.  As a special exception to the GNU General
 dnl Public License, this file may be distributed as part of a program
@@ -9,6 +9,6 @@ dnl the same distribution terms as the r
 AC_DEFUN([gl_SAME],
 [
   dnl Prerequisites of lib/same.c.
-  AC_CHECK_HEADERS_ONCE(stdlib.h string.h unistd.h)
-  AC_CHECK_DECLS_ONCE(free)
+  AC_CHECK_HEADERS_ONCE(unistd.h)
+  AC_CHECK_FUNCS(pathconf)
 ])



___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils


Re: coreutils-5.0.90 problems on Crays

2003-08-18 Thread Paul Eggert
Wendy Palm [EMAIL PROTECTED] writes:

 with the change i proposed, the only error i have with the tests is
 date-tests and i haven't had time to check what that problem is yet.

I doubt whether the tests exercise the md5 and sha code a lot, and I
suspect that there will be latent bugs, unless someone carefully inspects
the code and makes sure that there are no problems.

 i'd be interested to know what programs are potentially problems with 32bits.
 possibly some shifting assumptions may be messed up.

For example, here's the first use of md5_uint32 in md5.c:

  ((md5_uint32 *) resbuf)[0] = SWAP (ctx-A);

SWAP is defined as follows:

#ifdef WORDS_BIGENDIAN
# define SWAP(n)\
(((n)  24) | (((n)  0xff00)  8) | (((n)  8)  0xff00) | ((n)  24))
#else
# define SWAP(n) (n)
#endif

If Cray is a WORDS_BIGENDIAN host, this will put garbage bits into the
high-order part of ((md5_uint32 *) resbuf)[0].

This is just the first occurrence that I found.  Basically, someone
needs to check every instance of md5_uint32 and make sure that it
works OK.

  cc  -hnointrinsics  -Wl,-Dmsglevel=334:fatal -o [  lbracket.o 
 ../lib/libfetish.a  ../lib/libfetish.a -lgen
 GETTMC: invalid primary machine name on TARGET statement

Does it work to change the -o [ to -o lbracket, and then to
issue mv [ lbracket afterwards?


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils