Re: [bug-gnulib] New GNULIB glob module?

2005-05-18 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes:

But let's step back a second. Why are we worried about building
gnulib glob.c under glibc? It will never happen, right? So perhaps
we needn't worry about this problem at all.

 Won't it?  I thought the idea was that when you and I settled on
 something that looked good I would attempt to send it back to the libc
 folks so that the files wouldn't need to be maintained separately.

Yes, that's the idea, but that's a different scenario.  In that
scenario we are building glob.c as part of glibc, so _LIBC is 1.  I am
talking about the scenario where glob.c is part of a user program
(i.e., glob.c is imported from gnulib), and where the C library is
glibc, but we are compiling glob.c anyway.  Will that ever happen?

Answering my own question: yes it will, in general, because perhaps
the gnulib version fixes a bug that's in the glibc version, and the
user wants the gnulib version.  So we should worry about this.
And (as far as I can see) the simplest fix is to do this:

#if defined _LIBC || HAVE_SYS_CDEFS_H
# include sys/cdefs.h
#endif

with the appropriate change to glob.m4 to define HAVE_SYS_CDEFS_H.


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


[bug-gnulib] Re: [PATCH]: fix warning in the hash module

2005-05-18 Thread Ian Abbott
On 17/05/2005 10:20, Yoann Vandoorselaere wrote:
However, I still consider this version of the patch to be a hack, when
the real bug here is that you should not use const since you permit the
user to free() the data from the interface callback. The interface
should not use const at all.
Can you show how the Hash_data_freer callback is called from 
hash_insert, because I can't see it!

--
-=( Ian Abbott @ MEV Ltd.E-mail: [EMAIL PROTECTED])=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587 )=-
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


Re: [bug-gnulib] gcc -Wall warning for minmax.h

2005-05-18 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes:

 Corrected patch attached.

Thanks.  A couple more things.  (Sorry I didn't catch it earlier.)
First, the $gl_* variables should be cached, with AC_CACHE_CHECK.
Second, suppose limits.h and sys/param.h have conflicting
definitions of MIN and MAX?  To work around the latter potential
problem you can #undef MIN and MAX after including limits.h.


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


[bug-gnulib] sync from coreutils for fts, gettimeofday, canonicalize

2005-05-18 Thread Paul Eggert
I installed this into gnulib.  This is just an internal cleanup; it
shouldn't affect behavior.

2005-05-18  Paul Eggert  [EMAIL PROTECTED]

* lib/canonicalize.c: Include canonicalize.h first, to test interface.
Include stddef.h unconditionally, since we assume C89 now.
All uses of PTR_INT_TYPE replaced by ptrdiff_t.
* lib/fts.c: Include fts_.h first, to check interface.
Do not include intprops.h; no longer needed.
Include cycle-check.h and hash.h, since fts_.h no longer does.
Remove unnecessary casts of closedir to void.
(fts_build): Use a simpler method (not involving TYPE_SIGNED) to
decide whether to decrement nlinks.
* lib/fts_.h: Do not include hash.h or cycle-check.h; no longer needed.
(FTS): Use struct hash_table * instead of Hash_table, so that
we no longer need to include hash.h here.

* m4/canonicalize.m4 (AC_FUNC_CANONICALIZE_FILE_NAME]):
Don't check for stddef.h.
* m4/fts.m4 (gl_FUNC_FTS): Don't require AC_HEADER_STDC, as we
don't use its results.
Don't check for fcntl.h, stddef.h, stdlib.h, string.h, unistd.h,
since we include them unconditionally.  Don't require
AM_STDBOOL_H, since stdbool is a prerequisite.
Don't require AC_C_CONST, AC_TYPE_SIZE_T or check for ptrdiff_t
since we assume C89 or better.
Don't require AC_FUNC_CLOSEDIR_VOID, AC_FUNC_LSTAT, or AC_FUNC_STAT,
as we don't use their results.
Don't check for fchdir, memmove, memset, strrchr, as we use
them unconditionally.
* m4/gettimeofday.m4 (AC_FUNC_GETTIMEOFDAY_CLOBBER): Don't define
GETTIMEOFDAY_CLOBBERS_LOCALTIME_BUFFER, since nobody uses it.

Index: lib/canonicalize.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/canonicalize.c,v
retrieving revision 1.3
diff -p -u -r1.3 canonicalize.c
--- lib/canonicalize.c  14 May 2005 06:03:57 -  1.3
+++ lib/canonicalize.c  18 May 2005 19:43:49 -
@@ -20,6 +20,8 @@
 # include config.h
 #endif
 
+#include canonicalize.h
+
 #ifdef STDC_HEADERS
 # include stdlib.h
 #else
@@ -43,6 +45,7 @@ void free ();
 #endif
 
 #include errno.h
+#include stddef.h
 
 #include cycle-check.h
 #include path-concat.h
@@ -54,24 +57,6 @@ void free ();
 # define __set_errno(Val) errno = (Val)
 #endif
 
-/* If __PTRDIFF_TYPE__ is
-   defined, as with GNU C, use that; that way we don't pollute the
-   namespace with stddef.h's symbols.  Otherwise, if stddef.h is
-   available, include it and use ptrdiff_t.  In traditional C, long is
-   the best that we can do.  */
-
-#ifdef __PTRDIFF_TYPE__
-# define PTR_INT_TYPE __PTRDIFF_TYPE__
-#else
-# ifdef HAVE_STDDEF_H
-#  include stddef.h
-#  define PTR_INT_TYPE ptrdiff_t
-# else
-#  define PTR_INT_TYPE long
-# endif
-#endif
-
-#include canonicalize.h
 #include pathmax.h
 #include xreadlink.h
 
@@ -230,7 +215,7 @@ canonicalize_filename_mode (const char *
 
  if (dest + (end - start) = rpath_limit)
{
- PTR_INT_TYPE dest_offset = dest - rpath;
+ ptrdiff_t dest_offset = dest - rpath;
  size_t new_size = rpath_limit - rpath;
 
  if (end - start + 1  PATH_MAX)
Index: lib/fts.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/fts.c,v
retrieving revision 1.1
diff -p -u -r1.1 fts.c
--- lib/fts.c   17 May 2005 07:07:19 -  1.1
+++ lib/fts.c   18 May 2005 19:43:49 -
@@ -53,6 +53,8 @@
 static char sccsid[] = @(#)fts.c  8.6 (Berkeley) 8/14/94;
 #endif /* LIBC_SCCS and not lint */
 
+#include fts_.h
+
 #if HAVE_SYS_PARAM_H || defined _LIBC
 # include sys/param.h
 #endif
@@ -64,9 +66,10 @@ static char sccsid[] = @(#)fts.c8.6 (B
 #include fcntl.h
 #include errno.h
 #include dirfd.h
-#include fts_.h
-#include intprops.h
+#include cycle-check.h
+#include hash.h
 #include unistd-safer.h
+#include stdbool.h
 #include stdlib.h
 #include string.h
 #include unistd.h
@@ -926,7 +929,7 @@ fts_build (register FTS *sp, int type)
cur-fts_flags |= FTS_DONTCHDIR;
descend = false;
cderrno = errno;
-   (void)closedir(dirp);
+   closedir(dirp);
dirp = NULL;
} else
descend = true;
@@ -976,7 +979,7 @@ mem1:   saved_errno = errno;
if (p)
free(p);
fts_lfree(head);
-   (void)closedir(dirp);
+   closedir(dirp);
cur-fts_info = FTS_ERR;
SET(FTS_STOP);
__set_errno (saved_errno);
@@ -1001,7 +1004,7 @@ mem1: saved_errno = 

Re: [bug-gnulib] Re: coreutils FTS inclusion

2005-05-18 Thread Paul Eggert
Yoann Vandoorselaere [EMAIL PROTECTED] writes:

 There is also a problem with the 'intprops.h' dependency. 
 When gnulib-tool is run, the file is included, but it doesn't seem to be
 listed as part of the generated Makefile.am, leading to 'dist' trouble.

I have removed this dependency; fts no longer uses intprops.h.


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib