utimens merge from coreutils to support "touch -"

[Paul Eggert]

I installed this to merge from coreutils the support for "touch -":

2005-09-24  Paul Eggert  <[EMAIL PROTECTED]>

* utimens.c (ENOSYS): Define if not already defined.
(futimens): Support having a null PATH if the file descriptor
is nonnegative.

Index: utimens.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/utimens.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -p -u -r1.5 -r1.6
--- utimens.c   23 Sep 2005 19:18:06 -  1.5
+++ utimens.c   25 Sep 2005 06:22:35 -  1.6
@@ -41,6 +41,16 @@ struct utimbuf
 };
 #endif
 
+/* Some systems don't have ENOSYS.  */
+#ifndef ENOSYS
+# ifdef ENOTSUP
+#  define ENOSYS ENOTSUP
+# else
+/* Some systems don't have ENOTSUP either.  */
+#  define ENOSYS EINVAL
+# endif
+#endif
+
 #if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 8) || __STRICT_ANSI__
 # define __attribute__(x)
 #endif
@@ -53,7 +63,11 @@ struct utimbuf
TIMESPEC[0] and TIMESPEC[1], respectively.
FD must be either negative -- in which case it is ignored --
or a file descriptor that is open on FILE.
-   If TIMESPEC is null, set the time stamps to the current time.  */
+   If FD is nonnegative, then FILE can be NULL, which means
+   use just futimes (or equivalent) instead of utimes (or equivalent),
+   and fail if on an old system without futimes (or equivalent).
+   If TIMESPEC is null, set the time stamps to the current time.
+   Return 0 on success, -1 (setting errno) on failure.  */
 
 int
 futimens (int fd ATTRIBUTE_UNUSED,
@@ -78,8 +92,7 @@ futimens (int fd ATTRIBUTE_UNUSED,
 
 # if HAVE_FUTIMESAT
   return fd < 0 ? futimesat (AT_FDCWD, file, t) : futimesat (fd, NULL, t);
-# else
-#  if HAVE_FUTIMES
+# elif HAVE_FUTIMES
   if (0 <= fd)
 {
   if (futimes (fd, t) == 0)
@@ -97,23 +110,35 @@ futimens (int fd ATTRIBUTE_UNUSED,
  return -1;
}
 }
-#  endif
-  return utimes (file, t);
 # endif
+#endif
 
-#else
+#if ! HAVE_FUTIMES_AT
 
-  struct utimbuf utimbuf;
-  struct utimbuf const *t;
-  if (timespec)
+  if (!file)
 {
-  utimbuf.actime = timespec[0].tv_sec;
-  utimbuf.modtime = timespec[1].tv_sec;
-  t = &utimbuf;
+  errno = ENOSYS;
+  return -1;
 }
-  else
-t = NULL;
-  return utime (file, t);
+
+# if HAVE_WORKING_UTIMES
+  return utimes (file, t);
+# else
+  {
+struct utimbuf utimbuf;
+struct utimbuf const *ut;
+if (timespec)
+  {
+   utimbuf.actime = timespec[0].tv_sec;
+   utimbuf.modtime = timespec[1].tv_sec;
+   ut = &utimbuf;
+  }
+else
+  ut = NULL;
+
+return utime (file, ut);
+  }
+# endif
 
 #endif
 }


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

Re: regex workaround for gcc 2.95.3 core dump

[Paul Eggert]

Derek Price <[EMAIL PROTECTED]> writes:

> . 

Thanks for mentioning that.  Can you believe that I had forgotten all
about our earlier fix?  Anyway, I installed that patch in both
coreutils and gnulib, with this changelog entry:

2005-09-24  Paul Eggert  <[EMAIL PROTECTED]>

* regex_internal.h (__GNUC_PREREQ, always_inline, inline, pure):
Remove.
(__attribute): Define to empty unless GCC 3.1 or later.
This works around a core dump on OpenBSD 3.4, which has GCC
2.95.3, which dumps core when given __attribute__(()).  It also
simplifies other tests, since we really don't want to bother with
worrying about which ancient version of GCC supported what.
Original problem reported by Yoann Vandoorselaere, with part of
the fix suggested by Derek Price.


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

Re: regex workaround for gcc 2.95.3 core dump

[Derek Price]

Paul,

This is the same problem I ran into a few days ago on several platforms,
and you helped me come up with this patch:
. 
The patch in that message also removes a little cruft and handles a
similar problem in a later GCC with always_inline, by ignoring
__attribute__ for GCC < 3.1.

Regards,

Derek


Paul Eggert wrote:

>I installed the following to work around a build failure of coreutils
>CVS on OpenBSD 3.4.  (For now I have resisted the temptation to enable
>__attribute__ only for GCC 4.0 and later.  :-)
>
>2005-09-24  Paul Eggert  <[EMAIL PROTECTED]>
>
>   * regex_internal.h (__attribute): Define to nothing for GCC 2.
>   This works around a core dump on OpenBSD 3.4, which has GCC
>   2.95.3, which dumps core when given __attribute__(()).
>
>--- lib/regex_internal.h   23 Sep 2005 04:15:13 -  1.17
>+++ lib/regex_internal.h   24 Sep 2005 23:01:17 -  1.18
>@@ -131,7 +131,7 @@
> # define attribute_hidden
> #endif /* not _LIBC */
> 
>-#ifdef __GNUC__
>+#if __GNUC__ >= 3
> # define __attribute(arg) __attribute__ (arg)
> #else
> # define __attribute(arg)
>
>
>___
>bug-gnulib mailing list
>bug-gnulib@gnu.org
>http://lists.gnu.org/mailman/listinfo/bug-gnulib
>  
>


-- 
Derek R. Price
CVS Solutions Architect
Ximbiot 
v: +1 717.579.6168
f: +1 717.234.3125





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

regex workaround for gcc 2.95.3 core dump

[Paul Eggert]

I installed the following to work around a build failure of coreutils
CVS on OpenBSD 3.4.  (For now I have resisted the temptation to enable
__attribute__ only for GCC 4.0 and later.  :-)

2005-09-24  Paul Eggert  <[EMAIL PROTECTED]>

* regex_internal.h (__attribute): Define to nothing for GCC 2.
This works around a core dump on OpenBSD 3.4, which has GCC
2.95.3, which dumps core when given __attribute__(()).

--- lib/regex_internal.h23 Sep 2005 04:15:13 -  1.17
+++ lib/regex_internal.h24 Sep 2005 23:01:17 -  1.18
@@ -131,7 +131,7 @@
 # define attribute_hidden
 #endif /* not _LIBC */
 
-#ifdef __GNUC__
+#if __GNUC__ >= 3
 # define __attribute(arg) __attribute__ (arg)
 #else
 # define __attribute(arg)


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

problem with mbchar module on OpenBSD

[Paul Eggert]

With coreutils CVS on OpenBSD 3.4, I ran into the same problem with
the mbchar module that Yoann Vandoorselaere first reported with OpenBSD 3.7 in
.

I installed the following patch into coreutils, which is about the
same as Derek Price's proposed gnulib patch
.

2005-09-24  Paul Eggert  <[EMAIL PROTECTED]>

* lib/Makefile.am (libcoreutils_a_SOURCES): Remove mbchar.c, since
it doesn't build in OpenBSD 3.4.  See
.
* m4/mbchar.m4 (gl_MBCHAR): Check for wchar.h and wctype.h, and
don't compile mbchar.c unless both headers exist.  See
.

--- lib/Makefile.am 22 Sep 2005 06:58:56 -  1.233
+++ lib/Makefile.am 24 Sep 2005 23:06:14 -
@@ -35,7 +35,7 @@ libcoreutils_a_SOURCES = \
   getaddrinfo.h \
   gettext.h \
   localcharset.c localcharset.h \
-  mbchar.c mbchar.h \
+  mbchar.h \
   mbswidth.c mbswidth.h \
   mbuiter.h \
   readtokens0.c readtokens0.h \
--- m4/mbchar.m422 Sep 2005 06:22:44 -  1.1
+++ m4/mbchar.m424 Sep 2005 23:06:14 -
@@ -1,4 +1,4 @@
-# mbchar.m4 serial 1
+# mbchar.m4 serial 2
 dnl Copyright (C) 2005 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -9,6 +9,13 @@ dnl From Bruno Haible.
 
 AC_DEFUN([gl_MBCHAR],
 [
+  AC_CHECK_HEADERS_ONCE(wchar.h wctype.h)
+
+  case $ac_cv_header_wchar_h,$ac_cv_header_wctype_h in
+  yes,yes)
+AC_LIBOBJ([mbchar]);;
+  esac
+
   AC_REQUIRE([AC_GNU_SOURCE])
   :
 ])


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

gethostbyname on Solaris 5.7

[Jim Meyering]

Here's a log of a failed Solaris 5.7 build

  cc  -I/usr/local/include  -R/usr/local/lib -L/usr/local/lib -o pinky  pinky.o 
../lib/libcoreutils.a /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -lc 
-R/usr/local/lib ../lib/libcoreutils.a
  Undefined   first referenced
   symbol in file
  gethostbyname   ../lib/libcoreutils.a(getaddrinfo.o)
  getservbyname   ../lib/libcoreutils.a(getaddrinfo.o)
  ld: fatal: Symbol referencing errors. No output written to pinky
  make[3]: *** [pinky] Error 1

The problem was that coreutils no longer had the check for -lnsl.
coreutils-5.3.0 had that test in canon-host.m4, and now that canon-host
is just a wrapper around getaddrinfo, it's appropriate that it no longer
perform this check.  So getaddrinfo.m4 must do it, now,
and I've made the following change in coreutils, and
will commit it to gnulib as soon as I've confirmed it works.

2005-09-24  Jim Meyering  <[EMAIL PROTECTED]>

* getaddrinfo.m4 (gl_GETADDRINFO): Check for gethostbyname
in the inet and nsl libraries.  Required on Solaris 5.7.

Index: m4/getaddrinfo.m4
===
RCS file: /fetish/cu/m4/getaddrinfo.m4,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -u -r1.4 -r1.5
--- m4/getaddrinfo.m4   23 Sep 2005 19:40:04 -  1.4
+++ m4/getaddrinfo.m4   24 Sep 2005 10:44:30 -  1.5
@@ -1,4 +1,4 @@
-# getaddrinfo.m4 serial 4
+# getaddrinfo.m4 serial 5
 dnl Copyright (C) 2004, 2005 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -7,6 +7,7 @@ dnl with or without modifications, as lo
 AC_DEFUN([gl_GETADDRINFO],
 [
   AC_SEARCH_LIBS(getaddrinfo, nsl socket)
+  AC_SEARCH_LIBS(gethostbyname, [inet nsl])
   AC_REPLACE_FUNCS(getaddrinfo gai_strerror)
   gl_PREREQ_GETADDRINFO
 ])


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

Re: getaddrinfo needs socklen, sync from coreutils

[Simon Josefsson]

Jim Meyering <[EMAIL PROTECTED]> writes:

> Simon Josefsson <[EMAIL PROTECTED]> wrote:
>
>> Jim Meyering <[EMAIL PROTECTED]> writes:
>>
>>> I've just discovered/fixed a build problem with the getaddrinfo module.
>>> It didn't depend on the socklen module (for the declaration of socklen_t).
>>> So I've merged these changes from coreutils:
>>
>> Hm. socklen_t is POSIX.  Shouldn't getaddrinfo assume a POSIX system
>> except for getaddrinfo?  If a maintainer notice that socklen_t is ALSO
>> missing he could use the socklen_t module herself.
>
> Hi Simon,
>
> I don't understand your suggestion.
> Why would you *not* want to make the getaddrinfo module depend on
> the socklen one?  configure-time overhead?
>
> The whole idea of gnulib is to provide as consistent a development
> environment as possible.  Sometimes that means declaring types, including
> replacement header files, defining/linking-to replacement functions, etc.
> that are more consistent with our desired environment (often POSIX, but
> also with things from the GNU C library).  The goal is that the applications
> using gnulib can code to this idealized environment, with a minimum of
> kludges, #ifdef's, work-arounds, etc.
>
> The goal of each module should be to insulate the developer from the
> vagaries and portability problems of the less-conforming systems we use.
> Not having a socklen_t type is one problem that can arise, so any module
> that uses that type should depend on the one (socklen) that ensures
> the type is declared.

You are right, never mind.  I was thinking of a similar situation with
strdup: I thought many modules used strdup without depending on the
strdup module, or even including strdup.h.  The reason would be that
other gnulib modules should be able to simply assume GNU features such
as strdup.  But a few grep suggest this wasn't the case.  Depending on
socklen_t in getaddrinfo thus simplify thing and, more importantly, is
consistent with the strdup situation.

Regards,
Simon


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

Re: getaddrinfo needs socklen, sync from coreutils

[Jim Meyering]

Simon Josefsson <[EMAIL PROTECTED]> wrote:

> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> I've just discovered/fixed a build problem with the getaddrinfo module.
>> It didn't depend on the socklen module (for the declaration of socklen_t).
>> So I've merged these changes from coreutils:
>
> Hm. socklen_t is POSIX.  Shouldn't getaddrinfo assume a POSIX system
> except for getaddrinfo?  If a maintainer notice that socklen_t is ALSO
> missing he could use the socklen_t module herself.

Hi Simon,

I don't understand your suggestion.
Why would you *not* want to make the getaddrinfo module depend on
the socklen one?  configure-time overhead?

The whole idea of gnulib is to provide as consistent a development
environment as possible.  Sometimes that means declaring types, including
replacement header files, defining/linking-to replacement functions, etc.
that are more consistent with our desired environment (often POSIX, but
also with things from the GNU C library).  The goal is that the applications
using gnulib can code to this idealized environment, with a minimum of
kludges, #ifdef's, work-arounds, etc.

The goal of each module should be to insulate the developer from the
vagaries and portability problems of the less-conforming systems we use.
Not having a socklen_t type is one problem that can arise, so any module
that uses that type should depend on the one (socklen) that ensures
the type is declared.

> Just a thought.
> For this case adding the dependency is low-cost, but in general it
> could have been a very complex module that were added.


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

Re: getaddrinfo needs socklen, sync from coreutils

[Simon Josefsson]

Jim Meyering <[EMAIL PROTECTED]> writes:

> I've just discovered/fixed a build problem with the getaddrinfo module.
> It didn't depend on the socklen module (for the declaration of socklen_t).
> So I've merged these changes from coreutils:

Hm. socklen_t is POSIX.  Shouldn't getaddrinfo assume a POSIX system
except for getaddrinfo?  If a maintainer notice that socklen_t is ALSO
missing he could use the socklen_t module herself.  Just a thought.
For this case adding the dependency is low-cost, but in general it
could have been a very complex module that were added.

Thanks,
Simon


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