Tempdir is not removed.

2011-06-18 Thread John Darrington
The comment in clean-temp.h says that temp files/directories will be 
"automatically removed when the program exits either normally or through a 
fatal signal" .

However, the code in clean-temp.c seems only to deal with the fatal signal case.
Consequently, in most cases, they don't get removed (observed on GNU/Linux as
well as w32).  

Should there not be a call to at_exit in this module?

J'


-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.



signature.asc
Description: Digital signature


Re: Tempdir is not removed.

2011-06-18 Thread Bruno Haible
Hi,

John Darrington wrote:
> The comment in clean-temp.h says that temp files/directories will be 
> "automatically removed when the program exits either normally or through a 
> fatal signal" .
> 
> However, the code in clean-temp.c seems only to deal with the fatal signal 
> case.
> Consequently, in most cases, they don't get removed (observed on GNU/Linux as
> well as w32).  
> 
> Should there not be a call to at_exit in this module?

That wording is ambiguous indeed. The wording "automatically removed when the
program exits" is meant from the perspective of the end user, not from the
perspective of the programmer.

The module does not call atexit() because that does not work well for complex
programs: There is no way to guarantee an order of execution of multiple atexit
hooks.

I'm updating the documentation:


2011-06-18  Bruno Haible  

clean-temp: Improve documentation.
* lib/clean-temp.h: Explain better how to use this module.
Reported by John Darrington .

--- lib/clean-temp.h.orig   Sat Jun 18 11:22:23 2011
+++ lib/clean-temp.hSat Jun 18 11:22:02 2011
@@ -43,7 +43,12 @@
are automatically cleaned up (at the latest) when the program exits or
dies from a fatal signal such as SIGINT, SIGTERM, SIGHUP, but not if it
dies from a fatal signal such as SIGQUIT, SIGKILL, or SIGABRT, SIGSEGV,
-   SIGBUS, SIGILL, SIGFPE.  */
+   SIGBUS, SIGILL, SIGFPE.
+
+   For the cleanup in the normal case, programs that use this module need to
+   call 'cleanup_temp_dir' for each successful return of 'create_temp_dir'.
+   The cleanup in the case of a fatal signal such as SIGINT, SIGTERM, SIGHUP,
+   is done entirely automatically by the functions of this module.  */
 
 struct temp_dir
 {

-- 
In memoriam Mona Mahmudnizhad 



Re: [PATCH 0/348] move AC_LIBOBJ invocations to the module descriptions

2011-06-18 Thread Tom G. Christensen

On 06/16/2011 12:12 AM, Bruno Haible wrote:

I wrote:

Please review and comment. I'll wait for objections for a week.


The week is over. I have now pushed the series of patches, after doing an
additional test with --create-megatestdir.


I found another regression from this patch series.

On Solaris 2.6 test-getloadavg now fails to link:
gcc -std=gnu99  -g -O2  -L/usr/tgcware/lib -Wl,-R,/usr/tgcware/lib -o 
test-getloadavg test-getloadavg.o ../gllib/libgnu

.a -lkvm -lelf  -lm   -lm -lm-lm  -lm  -lm
Undefined   first referenced
 symbol in file
kstat_close ../gllib/libgnu.a(getloadavg.o)
kstat_lookup../gllib/libgnu.a(getloadavg.o)
kstat_read  ../gllib/libgnu.a(getloadavg.o)
kstat_open  ../gllib/libgnu.a(getloadavg.o)
kstat_data_lookup   ../gllib/libgnu.a(getloadavg.o)
ld: fatal: Symbol referencing errors. No output written to test-getloadavg

The problem is that '-lkstat' is missing from GETLOADAVG_LIBS.
The cause for that is gl_PREREQ_GETLOADAVG nolonger being called from 
inside gl_GETLOADAVG where GETLOADAVG_LIBS is being determined, but after.


-tgc



Re: [PATCH 0/348] move AC_LIBOBJ invocations to the module descriptions

2011-06-18 Thread Bruno Haible
Hi,

Tom G. Christensen wrote:
> I found another regression from this patch series.
> 
> On Solaris 2.6 test-getloadavg now fails to link:
> gcc -std=gnu99  -g -O2  -L/usr/tgcware/lib -Wl,-R,/usr/tgcware/lib -o 
> test-getloadavg test-getloadavg.o ../gllib/libgnu
> .a -lkvm -lelf  -lm   -lm -lm-lm  -lm  -lm
> Undefined   first referenced
>   symbol in file
> kstat_close ../gllib/libgnu.a(getloadavg.o)
> kstat_lookup../gllib/libgnu.a(getloadavg.o)
> kstat_read  ../gllib/libgnu.a(getloadavg.o)
> kstat_open  ../gllib/libgnu.a(getloadavg.o)
> kstat_data_lookup   ../gllib/libgnu.a(getloadavg.o)
> ld: fatal: Symbol referencing errors. No output written to test-getloadavg
> 
> The problem is that '-lkstat' is missing from GETLOADAVG_LIBS.
> The cause for that is gl_PREREQ_GETLOADAVG nolonger being called from 
> inside gl_GETLOADAVG where GETLOADAVG_LIBS is being determined, but after.

Well spotted! I don't reproduce the link error, because '-lkstat' ends up
in LIBS instead of GETLOADAVG_LIBS:

  S["GETLOADAVG_LIBS"]="-lkvm -lelf "
  S["LIBS"]="-lkstat "

But we don't want to fill up LIBS, because only those executables that need
getloadavg() ought to be linked against libkstat. I'm committing this fix,
that reverts to the previous situation:

  S["GETLOADAVG_LIBS"]="-lkstat -lkvm -lelf "
  S["LIBS"]=""


2011-06-18  Bruno Haible  

getloadavg: Don't clobber LIBS. Regression from previous commit.
* m4/getloadavg.m4 (gl_PREREQ_GETLOADAVG): Move tests that use
AC_CHECK_LIB from here...
(gl_GETLOADAVG): ... to here, inside the experiment with LIBS.
(gl_GETLOADAVG, gl_PREREQ_GETLOADAVG): Rename gl_have_func to
gl_func_getloadavg_done.
Reported by Tom G. Christensen .

--- m4/getloadavg.m4.orig   Sat Jun 18 18:28:58 2011
+++ m4/getloadavg.m4Sat Jun 18 17:57:41 2011
@@ -26,34 +26,51 @@
 # NetBSD >= 0.9, OpenBSD >= 2.0, Solaris >= 7.
 HAVE_GETLOADAVG=1
 AC_CHECK_FUNC([getloadavg], [],
-  [gl_have_func=no
+  [gl_func_getloadavg_done=no
 
# Some systems with -lutil have (and need) -lkvm as well, some do not.
# On Solaris, -lkvm requires nlist from -lelf, so check that first
# to get the right answer into the cache.
# For kstat on solaris, we need to test for libelf and libkvm to force the
# definition of SVR4 below.
-   if test $gl_have_func = no; then
+   if test $gl_func_getloadavg_done = no; then
  AC_CHECK_LIB([elf], [elf_begin], [LIBS="-lelf $LIBS"])
  AC_CHECK_LIB([kvm], [kvm_open], [LIBS="-lkvm $LIBS"])
  # Check for the 4.4BSD definition of getloadavg.
  AC_CHECK_LIB([util], [getloadavg],
-   [LIBS="-lutil $LIBS" gl_have_func=yes])
+   [LIBS="-lutil $LIBS" gl_func_getloadavg_done=yes])
fi
 
-   if test $gl_have_func = no; then
+   if test $gl_func_getloadavg_done = no; then
  # There is a commonly available library for RS/6000 AIX.
  # Since it is not a standard part of AIX, it might be installed locally.
  gl_getloadavg_LIBS=$LIBS
  LIBS="-L/usr/local/lib $LIBS"
  AC_CHECK_LIB([getloadavg], [getloadavg],
-  [LIBS="-lgetloadavg $LIBS" gl_have_func=yes],
+  [LIBS="-lgetloadavg $LIBS" gl_func_getloadavg_done=yes],
   [LIBS=$gl_getloadavg_LIBS])
fi
 
# Set up the replacement function if necessary.
-   if test $gl_have_func = no; then
+   if test $gl_func_getloadavg_done = no; then
  HAVE_GETLOADAVG=0
+
+ # Solaris has libkstat which does not require root.
+ AC_CHECK_LIB([kstat], [kstat_open])
+ test $ac_cv_lib_kstat_kstat_open = yes && gl_func_getloadavg_done=yes
+
+ # AIX has libperfstat which does not require root
+ if test $gl_func_getloadavg_done = no; then
+   AC_CHECK_LIB([perfstat], [perfstat_cpu_total])
+   test $ac_cv_lib_perfstat_perfstat_cpu_total = yes && 
gl_func_getloadavg_done=yes
+ fi
+
+ if test $gl_func_getloadavg_done = no; then
+   AC_CHECK_HEADER([sys/dg_sys_info.h],
+ [gl_func_getloadavg_done=yes
+  AC_DEFINE([DGUX], [1], [Define to 1 for DGUX with 
.])
+  AC_CHECK_LIB([dgc], [dg_sys_info])])
+ fi
fi])
 
 if test "x$gl_save_LIBS" = x; then
@@ -88,52 +105,35 @@
 [
 # Figure out what our getloadavg.c needs.
 
-# Solaris has libkstat which does not require root.
-AC_CHECK_LIB([kstat], [kstat_open])
-test $ac_cv_lib_kstat_kstat_open = yes && gl_have_func=yes
-
 # On HPUX9, an unprivileged user can get load averages this way.
-if test $gl_have_func = no; then
-  AC_CHECK_FUNCS([pstat_getdynamic], [gl_have_func=yes])
-fi
-
-# AIX has libperfstat which does not require root
-if test $gl_have_func = no; then
-  AC_CHECK_LIB([perfstat], [perfstat_cpu_total])
-  test $ac_cv_lib_perfstat_perfstat_cpu_total = yes && gl_have_func=yes
-fi
-
-if test $gl_have_func = no; then
-  AC_CHEC

Re: bug#8881: config.h double inclusion

2011-06-18 Thread Bruce Korb

On 06/16/11 14:31, Jack Kelly wrote:

It might be better to have config.h do something like this:

#ifdef CONFIG_H
# error "config.h included twice"
#endif
#define CONFIG_H


Warning: Quite a few misbehaving packages actually install their config.h.


It might be better to have an autoconf macro, e.g.:
  AC_GUARD_CONFIG_H([MYPFX])

that adds multi-inclusion guards and prefixes the generated #define names.
I'm redirecting to that list.



isinf, isfinite on AIX

2011-06-18 Thread Bruno Haible
On AIX 6.1 and 7.1, the tests for isinf and isfinite don't link:

  xlc -D_ALL_SOURCE -O  -g   -o test-isinf test-isinf.o ../gllib/libgnu.a  
  ld: 0711-317 ERROR: Undefined symbol: ._isinff

  xlc -D_ALL_SOURCE -O  -g   -o test-isfinite test-isfinite.o ../gllib/libgnu.a 
 
  ld: 0711-317 ERROR: Undefined symbol: ._isfinitef

It would link if ISINF_LIBM and ISFINITE_LIBM were set to "-lm" instead of
empty. This fixes it:


2011-06-18  Bruno Haible  

isfinite, isinf: Fix link error on AIX 6 and 7.
* m4/isfinite.m4 (gl_ISFINITE): When determining whether libm is
needed, also test the macro with a 'float' argument.
* m4/isinf.m4 (gl_ISINF): Likewise.

--- m4/isfinite.m4.orig Sat Jun 18 20:23:29 2011
+++ m4/isfinite.m4  Sat Jun 18 20:22:06 2011
@@ -1,4 +1,4 @@
-# isfinite.m4 serial 9
+# isfinite.m4 serial 10
 dnl Copyright (C) 2007-2011 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -11,7 +11,8 @@
   AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
   AC_CHECK_DECLS([isfinite], , , [#include ])
   if test "$ac_cv_have_decl_isfinite" = yes; then
-gl_CHECK_MATH_LIB([ISFINITE_LIBM], [x = isfinite (x);])
+gl_CHECK_MATH_LIB([ISFINITE_LIBM],
+ [x = isfinite (x) + isfinite ((float) x);])
 if test "$ISFINITE_LIBM" != missing; then
   dnl Test whether isfinite() on 'long double' works.
   gl_ISFINITEL_WORKS
--- m4/isinf.m4.origSat Jun 18 20:23:29 2011
+++ m4/isinf.m4 Sat Jun 18 20:22:06 2011
@@ -1,4 +1,4 @@
-# isinf.m4 serial 4
+# isinf.m4 serial 5
 dnl Copyright (C) 2007-2011 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -11,7 +11,7 @@
   AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
   AC_CHECK_DECLS([isinf], , , [#include ])
   if test "$ac_cv_have_decl_isinf" = yes; then
-gl_CHECK_MATH_LIB([ISINF_LIBM], [x = isinf (x);])
+gl_CHECK_MATH_LIB([ISINF_LIBM], [x = isinf (x) + isinf ((float) x);])
 if test "$ISINF_LIBM" != missing; then
   dnl Test whether isinf() on 'long double' works.
   gl_ISINFL_WORKS


-- 
In memoriam Mona Mahmudnizhad 



PATH_MAX and test-stat.h

2011-06-18 Thread Bruno Haible
Hi Eric,

In pathmax.h one of the possible replacement values for PATH_MAX on systems
that don't define it (currently HP-UX and GNU/Hurd) is an expression
involving pathconf().

But tests/test-stat.h line 20 declares an array of size PATH_MAX. So - at
least with pre-C99 compilers - it is assuming that PATH_MAX is a constant.

Should we guarantee that PATH_MAX is a constant expression (by modifying
lib/pathmax.h), or change tests/test-stat.h to not assume it?

Bruno
-- 
In memoriam Mona Mahmudnizhad 



PATH_MAX on HP-UX

2011-06-18 Thread Bruno Haible
Hi,

On HP-UX 11.31 I'm seeing this compilation failure:

cc -Ae -D_XOPEN_SOURCE=500 -O -DHAVE_CONFIG_H -I.  -DGNULIB_STRICT_CHECKING=1 
-I. -I. -I.. -I./.. -I../gllib -I./../gllib 
-I/home/haible/prefix-hpux113-cc/include  -g -c -o test-getcwd.o test-getcwd.c
cc: "test-getcwd.c", line 53: error 1588: "PATH_MAX" undefined.
cc: "test-getcwd.c", line 53: error 1563: Expression in if must be scalar.
gmake[4]: *** [test-getcwd.o] Error 1

PATH_MAX on HP-UX 11.31 is
  1) not defined if _XOPEN_SOURCE is defined to 500 or greater,
  2) otherwise defined to 1023, with a comment saying
 "max number of characters in a pathname (not including terminating null)"

Apparently the reason is that POSIX specifies that PATH_MAX needs to include
the terminating NUL, but HP-UX PATH_MAX traditionally does not include it.
So they chose to remove PATH_MAX from their headers.

Here is a proposed patch. The second patch is obvious, I'm committing it
directly.


2011-06-18  Bruno Haible  

pathmax: Ensure correct value for PATH_MAX on HP-UX.
* lib/pathmax.h (PATH_MAX) [HP-UX]: Define to 1024.

--- lib/pathmax.h.orig  Sat Jun 18 22:07:53 2011
+++ lib/pathmax.h   Sat Jun 18 21:28:02 2011
@@ -19,6 +19,12 @@
 #ifndef _PATHMAX_H
 # define _PATHMAX_H
 
+/* POSIX:2008 defines PATH_MAX to be the maximum number of bytes in a filename,
+   including the terminating NUL byte.
+   
+   PATH_MAX is not defined on systems which have no limit on filename length,
+   such as GNU/Hurd.  */
+
 # include 
 
 # include 
@@ -45,4 +51,13 @@
 #  define PATH_MAX _POSIX_PATH_MAX
 # endif
 
+# ifdef __hpux
+/* On HP-UX, PATH_MAX designates the maximum number of bytes in a filename,
+   *not* including the terminating NUL byte, and is set to 1023.
+   Additionally, when _XOPEN_SOURCE is defined to 500 or more, PATH_MAX is
+   not defined at all any more.  */
+#  undef PATH_MAX
+#  define PATH_MAX 1024
+# endif
+
 #endif /* _PATHMAX_H */


2011-06-18  Bruno Haible  

getcwd tests: Avoid compilation error on HP-UX 11.31.
* modules/getcwd-tests (Depends-on): Add pathmax.
* tests/test-getcwd.c: Include pathmax.h.

--- modules/getcwd-tests.orig   Sat Jun 18 22:07:54 2011
+++ modules/getcwd-testsSat Jun 18 20:30:10 2011
@@ -5,6 +5,7 @@
 errno
 fcntl-h
 getcwd-lgpl
+pathmax
 sys_stat
 
 configure.ac:
--- tests/test-getcwd.c.origSat Jun 18 22:07:54 2011
+++ tests/test-getcwd.c Sat Jun 18 20:31:03 2011
@@ -26,6 +26,7 @@
 #include 
 #include 
 
+#include "pathmax.h"
 #include "macros.h"
 
 #if ! HAVE_GETPAGESIZE
-- 
In memoriam Mona Mahmudnizhad 



openat tests: link error

2011-06-18 Thread Bruno Haible
On HP-UX 11.31, I'm getting these link errors:

cc -Ae -D_XOPEN_SOURCE=500 -O  -g   -o test-fdopendir test-fdopendir.o 
libtests.a ../gllib/libgnu.a libtests.a
/usr/ccs/bin/ld: Unsatisfied symbols:
   program_name (first referenced in ../gllib/libgnu.a(error.o)) (data)
gmake[2]: *** [test-fdopendir] Error 1

cc -Ae -D_XOPEN_SOURCE=500 -O  -g   -o test-fchownat test-fchownat.o libtests.a 
../gllib/libgnu.a libtests.a
/usr/ccs/bin/ld: Unsatisfied symbols:
   program_name (first referenced in ../gllib/libgnu.a(error.o)) (data)
gmake[2]: *** [test-fchownat] Error 1

cc -Ae -D_XOPEN_SOURCE=500 -O  -g   -o test-fstatat test-fstatat.o libtests.a 
../gllib/libgnu.a libtests.a
/usr/ccs/bin/ld: Unsatisfied symbols:
   program_name (first referenced in ../gllib/libgnu.a(error.o)) (data)
gmake[2]: *** [test-fstatat] Error 1

cc -Ae -D_XOPEN_SOURCE=500 -O  -g   -o test-mkdirat test-mkdirat.o libtests.a 
../gllib/libgnu.a libtests.a
/usr/ccs/bin/ld: Unsatisfied symbols:
   program_name (first referenced in ../gllib/libgnu.a(error.o)) (data)
gmake[2]: *** [test-mkdirat] Error 1

cc -Ae -D_XOPEN_SOURCE=500 -O  -g   -o test-openat test-openat.o libtests.a 
../gllib/libgnu.a libtests.a
/usr/ccs/bin/ld: Unsatisfied symbols:
   program_name (first referenced in ../gllib/libgnu.a(error.o)) (data)
gmake[2]: *** [test-openat] Error 1

cc -Ae -D_XOPEN_SOURCE=500 -O  -g   -o test-unlinkat test-unlinkat.o libtests.a 
../gllib/libgnu.a libtests.a
/usr/ccs/bin/ld: Unsatisfied symbols:
   program_name (first referenced in ../gllib/libgnu.a(error.o)) (data)
gmake[2]: *** [test-unlinkat] Error 1

The reason is that these tests depend on the 'openat' module, which depends
on 'openat-die', which depends on 'error', which needs the 'program_name'
variable.

This fixes it:


2011-06-18  Bruno Haible  

openat, fdopendir tests: Fix link errors.
* modules/openat-tests (Depends-on): Add progname.
* modules/fdopendir-tests (Depends-on): Likewise.
* tests/test-fchownat.c: Include progname.h.
(main): Call set_program_name.
* tests/test-fstatat.c: Include progname.h.
(main): Call set_program_name.
* tests/test-mkdirat.c: Include progname.h.
(main): Call set_program_name.
* tests/test-openat.c: Include progname.h.
(main): Call set_program_name.
* tests/test-unlinkat.c: Include progname.h.
(main): Call set_program_name.
* tests/test-fdopendir.c: Include progname.h.
(main): Call set_program_name.

--- modules/fdopendir-tests.origSat Jun 18 23:03:18 2011
+++ modules/fdopendir-tests Sat Jun 18 22:55:41 2011
@@ -5,6 +5,7 @@
 
 Depends-on:
 open
+progname
 
 configure.ac:
 
--- modules/openat-tests.orig   Sat Jun 18 23:03:18 2011
+++ modules/openat-testsSat Jun 18 22:56:00 2011
@@ -19,6 +19,7 @@
 ignore-value
 mgetgroups
 pathmax
+progname
 usleep
 stat-time
 symlink
--- tests/test-fchownat.c.orig  Sat Jun 18 23:03:18 2011
+++ tests/test-fchownat.c   Sat Jun 18 22:55:11 2011
@@ -32,6 +32,7 @@
 
 #include "mgetgroups.h"
 #include "openat.h"
+#include "progname.h"
 #include "stat-time.h"
 #include "ignore-value.h"
 #include "macros.h"
@@ -58,11 +59,13 @@
 }
 
 int
-main (void)
+main (int argc _GL_UNUSED, char *argv[])
 {
   int result1; /* Skip because of no chown/symlink support.  */
   int result2; /* Skip because of no lchown support.  */
 
+  set_program_name (argv[0]);
+
   /* Clean up any trash from prior testsuite runs.  */
   ignore_value (system ("rm -rf " BASE "*"));
 
--- tests/test-fdopendir.c.orig Sat Jun 18 23:03:18 2011
+++ tests/test-fdopendir.c  Sat Jun 18 22:55:11 2011
@@ -27,14 +27,17 @@
 #include 
 #include 
 
+#include "progname.h"
 #include "macros.h"
 
 int
-main (void)
+main (int argc _GL_UNUSED, char *argv[])
 {
   DIR *d;
   int fd;
 
+  set_program_name (argv[0]);
+
   /* A non-directory cannot be turned into a directory stream.  */
   fd = open ("test-fdopendir.tmp", O_RDONLY | O_CREAT, 0600);
   ASSERT (0 <= fd);
--- tests/test-fstatat.c.orig   Sat Jun 18 23:03:18 2011
+++ tests/test-fstatat.cSat Jun 18 22:55:11 2011
@@ -32,6 +32,7 @@
 
 #include "openat.h"
 #include "pathmax.h"
+#include "progname.h"
 #include "same-inode.h"
 #include "ignore-value.h"
 #include "macros.h"
@@ -58,10 +59,12 @@
 }
 
 int
-main (void)
+main (int argc _GL_UNUSED, char *argv[])
 {
   int result;
 
+  set_program_name (argv[0]);
+
   /* Remove any leftovers from a previous partial run.  */
   ignore_value (system ("rm -rf " BASE "*"));
 
--- tests/test-mkdirat.c.orig   Sat Jun 18 23:03:18 2011
+++ tests/test-mkdirat.cSat Jun 18 22:55:11 2011
@@ -30,6 +30,7 @@
 #include 
 #include 
 
+#include "progname.h"
 #include "ignore-value.h"
 #include "macros.h"
 
@@ -47,10 +48,12 @@
 }
 
 int
-main (void)
+main (int argc _GL_UNUSED, char *argv[])
 {
   int result;
 
+  set_program_name (argv[0]);
+
   /* Clean up any trash from prior testsuite runs.  */
   ignore_value (system ("rm -rf " BASE "*"))

POSIX modules status

2011-06-18 Thread Bruno Haible
A testdir for all `./posix-modules` leads to the following test failures.

Summary:

 13 x FAIL: test-poll
 10 x FAIL: test-getcwd
  3 x FAIL: test-utimensat
  3 x FAIL: test-utimens
  3 x FAIL: test-perror2
  3 x FAIL: test-fsync
  3 x FAIL: test-ceilf-ieee
  2 x FAIL: test-vsprintf-posix
  2 x FAIL: test-vsnprintf-posix
  2 x FAIL: test-strerror_r
  2 x FAIL: test-sprintf-posix
  2 x FAIL: test-snprintf-posix
  2 x FAIL: test-roundl-ieee
  2 x FAIL: test-round-ieee
  2 x FAIL: test-roundf-ieee
  2 x FAIL: test-linkat
  2 x FAIL: test-isinf
  2 x FAIL: test-getlogin_r
  2 x FAIL: test-fclose
  2 x FAIL: test-ceil-ieee
  1 x FAIL: test-symlinkat
  1 x FAIL: test-renameat
  1 x FAIL: test-rename
  1 x FAIL: test-pread.sh
  1 x FAIL: test-nonblocking-pipe.sh
  1 x FAIL: test-mkfifoat
  1 x FAIL: test-glob
  1 x FAIL: test-getlogin
  1 x FAIL: test-futimens
  1 x FAIL: test-fstatat


Cygwin 1.5.x:

FAIL: test-getcwd.exe

test-nonblocking-writer.h:133: assertion failed
./test-nonblocking-pipe.sh: line 11:  1460 Segmentation fault
FAIL: test-nonblocking-pipe.sh

Unconnected socket test... passed
Connected sockets test... passed
General socket test with fork... passed
Pipe test... failed (expecting POLLHUP after shutdown)
FAIL: test-poll.exe


Cygwin 1.7.5:

Unconnected socket test... passed
Connected sockets test... failed (expecting POLLHUP after shutdown)
General socket test with fork... failed (expecting POLLHUP after shutdown)
Pipe test... failed (expecting POLLHUP after shutdown)
FAIL: test-poll.exe


Cygwin 1.7.9:

Unconnected socket test... passed
Connected sockets test... failed (expecting POLLHUP after shutdown)
General socket test with fork... failed (expecting POLLHUP after shutdown)
Pipe test... failed (expecting POLLHUP after shutdown)
FAIL: test-poll.exe

test-strerror_r.c:78: assertion failed
/bin/sh: line 5:  2424 Aborted
FAIL: test-strerror_r.exe

test-lutimens.h:126: assertion failed
/bin/sh: line 5:  2056 Aborted
FAIL: test-utimens.exe

test-lutimens.h:126: assertion failed
/bin/sh: line 5:  2308 Aborted
FAIL: test-utimensat.exe


MacOS X 10.5:

test-ceilf-ieee.c:52: assertion failed
/bin/sh: line 1: 81429 Abort trap
FAIL: test-ceilf-ieee

test-fsync.c:36: assertion failed
/bin/sh: line 1: 81704 Abort trap
FAIL: test-fsync

FAIL: test-getcwd


FreeBSD 6.4:

test-futimens.h:140: assertion failed
Abort trap (core dumped)
FAIL: test-futimens

FAIL: test-getcwd

test-isinf.c:151: assertion failed
Abort trap (core dumped)
FAIL: test-isinf

Unconnected socket test... passed
Connected sockets test... failed (expecting POLLHUP after shutdown)
General socket test with fork... failed (expecting POLLHUP after shutdown)
Pipe test... passed
FAIL: test-poll

test-rename.h:342: assertion failed
Abort trap (core dumped)
FAIL: test-rename

test-rename.h:342: assertion failed
Abort trap (core dumped)
FAIL: test-renameat

test-utimens.h:134: assertion failed
Abort trap (core dumped)
FAIL: test-utimens

test-utimens.h:134: assertion failed
Abort trap (core dumped)
FAIL: test-utimensat


OpenBSD 4.9:

FAIL: test-getcwd

test-isinf.c:213: assertion failed
Abort trap (core dumped) 
FAIL: test-isinf

test-perror2.c:112: assertion failed
Abort trap (core dumped) 
FAIL: test-perror2

Unconnected socket test... passed
Connected sockets test... failed (expecting POLLHUP after shutdown)
General socket test with fork... failed (expecting POLLHUP after shutdown)
Pipe test... passed
FAIL: test-poll

test-pread.c:71: assertion failed
Abort trap (core dumped) 
FAIL: test-pread.sh

test-strerror_r.c:69: assertion failed
Abort trap (core dumped) 
FAIL: test-strerror_r


AIX 6.1:

test-ceil-ieee.c:39: assertion failed
/bin/sh: 1081512 IOT/Abort trap(coredump)
FAIL: test-ceil-ieee

test-ceilf-ieee.c:52: assertion failed
/bin/sh: 1081526 IOT/Abort trap(coredump)
FAIL: test-ceilf-ieee

test-fclose.c:75: assertion failed
/bin/sh: 1081372 IOT/Abort trap(coredump)
FAIL: test-fclose

test-fsync.c:36: assertion failed
/bin/sh: 1081506 IOT/Abort trap(coredump)
FAIL: test-fsync

FAIL: test-getcwd

test-getlogin_r.c:44: assertion failed
/bin/sh: 1081582 IOT/Abort trap(coredump)
FAIL: test-getlogin_r

Unconnected socket test... passed
Connected sockets test... passed
General socket test with fork... passed
Pipe test... failed (expecting POLLIN | POLLRDNORM after writing)
  failed (expecting POLLIN after writing)
  failed (expecting POLLRDNORM after writing)
  failed (expecting POLLHUP after shutdown)
FAIL: test-poll

test-round-ieee.c:40: assertion failed
/bin/sh: 630872 IOT/Abort trap(coredump)
FAIL: test-round-ieee

test-roundf-ieee.c:40: assertion failed
/bin/sh: 630886 IOT/Abort trap(coredump)
FAIL: test-roundf-ieee

test-roundl-ieee.c:45: assertion failed
/bin/sh: 630900 IOT/Abort trap(coredump)
FAIL: test-roundl-ieee

test-snprintf-posix.h:3039: assertion failed
/bin/sh: 630974 IOT/Abort trap(coredump)
FAIL: test-snp

Re: error: avoid gcc warning

2011-06-18 Thread Bruno Haible
Eric Blake wrote on 2011-06-07:
> > It's because /usr/include/string.h on this system does not always declare
> > strerror_r (only if _REENTRANT or _THREAD_SAFE is defined). This fixes it
> > (without requiring the 'strerror_r' module).
> 
> This raises an interesting question.  The 'error' module should probably
> depend on strerror_r, not strerror.

But given that the 'strerror_r' module requires replacement code on many more
platforms, including glibc platforms, it feels like overkill. The current
situation is fine, IMO.

Bruno
-- 
In memoriam Mona Mahmudnizhad 



Re: PATH_MAX and test-stat.h

2011-06-18 Thread James Youngman
On Sat, Jun 18, 2011 at 8:33 PM, Bruno Haible  wrote:
> Hi Eric,
>
> In pathmax.h one of the possible replacement values for PATH_MAX on systems
> that don't define it (currently HP-UX and GNU/Hurd) is an expression
> involving pathconf().
>
> But tests/test-stat.h line 20 declares an array of size PATH_MAX. So - at
> least with pre-C99 compilers - it is assuming that PATH_MAX is a constant.
>
> Should we guarantee that PATH_MAX is a constant expression (by modifying
> lib/pathmax.h), or change tests/test-stat.h to not assume it?

It looks to me like POSIX doesn't state that PATH_MAX is a constant
expression.   There are other values in limits.h that POSIX states
must be constant expressions (for example, INT_MAX) so I think this is
deliberate.

I suspect that the most useful thing we can do in gnulib is define
PATH_MAX to a non-constant expression on all platforms, even the ones
in which it is normally a constant expression.   Otherwise maintainers
will find that their code works on their system but won't compile on
some other system they don't have access to.Clearly this position
on PATH_MAX could be taken to its logical conclusion of un-defining
the macro on all platforms to make sure that all GNU programs work on
Hurd, but I think that discussion has already been had.   In any case,
maintainers who want to go in for this can probably achieve the same
sort of effect with a syntax check.

As for tests/test-stat.h, I'm mildly surprised that we haven't seen
any systems where an auto buffer of size PATH_MAX blows the stack.
The only purpose for which test-stat.h uses this array is to verify
that stat-ing "." and cwd gives the same device/inode.   So for this
example we can probably just rely on getcwd-lgpl and call getcwd(NULL,
0).

James.



Re: PATH_MAX and test-stat.h

2011-06-18 Thread Paul Eggert
On 06/18/11 15:18, James Youngman wrote:
> I suspect that the most useful thing we can do in gnulib is define
> PATH_MAX to a non-constant expression on all platforms, even the ones
> in which it is normally a constant expression.

That goes a bit too far, I'd think.  Some code assumes
a constant PATH_MAX only on some platforms; for example, gnulib
lib/stat.c declares an array of size PATH_MAX + 1
only on MingW.  We don't want to reject usage like that.



Re: PATH_MAX and test-stat.h

2011-06-18 Thread Karl Berry
IMHO ...

I suspect that the most useful thing we can do in gnulib is define
PATH_MAX to a non-constant expression on all platforms, 

And intentionally break loads of existing code?
I am highly doubtful that that is "useful"; "painful" sounds more
accurate :).

I am aware that conceptually there is no PATH_MAX on Hurd and no
requirement for it to be a smallish constant, but it seems to me that
any real-world system has to define PATH_MAX as a reasonable constant
simply for compatibility with all the code that has been written with
that assumption over the last 30+ years.

maintainers who want to go in for this can probably achieve the same
sort of effect with a syntax check.

I agree with that, and I would extend it to the idea of PATH_MAX as a
non-constant.  Programmers who want to worry about it are free to do so
(and in GNU we *should* worry about it), but let's not impose it on
everyone.

k



Re: mingw flavours

2011-06-18 Thread Bruno Haible
Eric Blake explained on 2011-06-09:
> > what's the difference between
> > i686-pc-mingw32 and i686-w64-mingw32?
> 
> i686-pc-mingw32 is the old mingw32 project; it is not as actively
> maintained today, but is still the project used by cygwin.  Right now,
> it uses dwarf exceptions.
> 
> i686-w64-mingw32 is the new mingw (aka mingw64) project; it is currently
> more actively maintained, and the Fedora project is trying to switch
> over to this cross-compiler.  However, it still uses sjlj exceptions
> (worse performance on C++ code).  This generates 32-bit executables
> (despite the w64 in the name, and the mingw32 is a bit of a misnomer as
> well - but that's historical).
> 
> x86_64-w64-mingw32 also stems from the mingw (aka mingw64) project; it
> is the 64-bit counterpart.  ...

Thanks for all these explanations.

So, I will continue to put fixes regarding i686-pc-mingw32 into gnulib,
whereas when we find bugs for i686-w64-mingw32, it seems we should better
report them at 
or .

Bruno
-- 
In memoriam Mona Mahmudnizhad 



Re: PATH_MAX and test-stat.h

2011-06-18 Thread James Youngman
On Sat, Jun 18, 2011 at 11:24 PM, Karl Berry  wrote:
> IMHO ...
>
>    I suspect that the most useful thing we can do in gnulib is define
>    PATH_MAX to a non-constant expression on all platforms,
>
> And intentionally break loads of existing code?
> I am highly doubtful that that is "useful"; "painful" sounds more
> accurate :).

I much prefer obvious breakage, in which problem code simply fails to
compile, to subtle breakage where your code compiles on all the
systems you have access to but still has subtle problems.

I suppose this is a personal preference.


> I am aware that conceptually there is no PATH_MAX on Hurd and no
> requirement for it to be a smallish constant, but it seems to me that
> any real-world system has to define PATH_MAX as a reasonable constant
> simply for compatibility with all the code that has been written with
> that assumption over the last 30+ years.

Yes.   This will be the commercial vendors' position, certainly.
Breaking your customers' build makes your customers irritated, and
even a little of that causes sales to go elsewhere.   A defence that
you're doing it for your customer's (and their customers') own good
doesn't help a lot.   This is also why we still have broken interfaces
offered all over the place, like atoi and gets.

I spent a while writing safety-critical code.   This made me very
intolerant of situation where the computer can detect a problem with
the code but doesn't, in the name of the programmer's convenience.
Those kind of choices always came back to bite me.   Eventually I
found that for this kind of system, I was best served by library
interface designs in which it's either impossible to use them
incorrectly, or that something goes wrong every single time (as
opposed to rarely or worse, invisibly) when the code is wrong.
Perhaps the habits I learned in this process, while still helpful for
me in other fields, aren't really practical in all use cases.  For
example, not everybody wants to pay for more correctness by accepting
less convenience.

Please forgive me if I sound a bit dogmatic.

> Programmers who want to worry about it are free to do so
> (and in GNU we *should* worry about it), but let's not impose it on
> everyone.

I tend to assume that the intended audience for gnulib is maintainers
of GNU packages, but perhaps I'm a little too narrow in my view there.

James.



Re: [PATCH 1/2] Enable more syntax checks, eliminate useless C preprocessor parentheses

2011-06-18 Thread Bruno Haible
James, Eric,
> we're trying to get rid of a findutils construct:
> 
> -#if defined SIGCLD && !defined SIGCHLD
> -# define SIGCHLD SIGCLD
> -#endif
> 
> and need to know if gnulib's replacement  needs to guarantee
> this definition of SIGCHLD, or if the only platforms where only SIGCLD
> existed are now so old to not be worth worrying about.

As far as I can see, all platforms except native Windows nowadays have SIGCHLD.
- I find it defined in  or  of all relevant platforms.
- coreutils/src/{sort.c,timeout.c} use SIGCHLD unconditionally, and I'm not
  aware of a bug report because of that.

Bruno
-- 
In memoriam Mona Mahmudnizhad 



test-perror2 failures

2011-06-18 Thread Bruno Haible
Eric,

Here's some info about the test-perror2 failures:

>       3 x FAIL: test-perror2

All three failures at line 112: ASSERT (strstr (buf, err));

On OpenBSD 4.9:

i = 1, err = "Success", buf = "Undefined error: 0\n"

config.status:
S["REPLACE_STRERROR_R"]="1"
S["REPLACE_STRERROR"]="1"
S["HAVE_DECL_STRERROR_R"]="1"
S["REPLACE_PERROR"]="1"
S["GNULIB_STRERROR_R"]="1"
S["GNULIB_STRERROR"]="1"
S["GNULIB_PERROR"]="1"

On HP-UX 11.00 and IRIX 6.5:

i = 2, err = "Unknown error -3", buf = "Unknown error\n"

config.status:
S["REPLACE_STRERROR_R"]="0"
S["REPLACE_STRERROR"]="1"
S["HAVE_DECL_STRERROR_R"]="0"
S["REPLACE_PERROR"]="0"
S["GNULIB_STRERROR_R"]="1"
S["GNULIB_STRERROR"]="1"
S["GNULIB_PERROR"]="1"

Bruno
-- 
In memoriam Mona Mahmudnizhad 



test-fsync failures

2011-06-18 Thread Bruno Haible
>       3 x FAIL: test-fsync

When stdin is connected to a socket (or pipe?) set up by sshd:
- On MacOS X, fsync (0) fails with ENOTSUP instead of EINVAL.
- On AIX 7.1, fsync (0) fails with EBADF instead of EINVAL.

This patch fixes the failure, by relaxing the test.


2011-06-18  Bruno Haible  

fsync test: Avoid test failure on MacOS X and AIX.
* tests/test-fsync.c (fsync): Allow ENOTSUP and EBADF instead of
EINVAL.

--- tests/test-fsync.c.orig Sun Jun 19 03:12:30 2011
+++ tests/test-fsync.c  Sun Jun 19 03:11:31 2011
@@ -33,7 +33,12 @@
   const char *file = "test-fsync.txt";
 
   if (fsync (0) != 0)
-ASSERT (errno == EINVAL);
+{
+  ASSERT (errno == EINVAL /* POSIX */
+  || errno == ENOTSUP /* seen on MacOS X 10.5 */
+  || errno == EBADF /* seen on AIX 7.1 */
+ );
+}
   fd = open (file, O_WRONLY|O_CREAT|O_TRUNC, 0644);
   ASSERT (0 <= fd);
   ASSERT (write (fd, "hello", 5) == 5);

-- 
In memoriam Mona Mahmudnizhad 



Re: PATH_MAX and test-stat.h

2011-06-18 Thread Ralf Wildenhues
Hello,

* James Youngman wrote on Sun, Jun 19, 2011 at 12:57:01AM CEST:
> On Sat, Jun 18, 2011 at 11:24 PM, Karl Berry  wrote:
> >    I suspect that the most useful thing we can do in gnulib is define
> >    PATH_MAX to a non-constant expression on all platforms,
> >
> > And intentionally break loads of existing code?
> > I am highly doubtful that that is "useful"; "painful" sounds more
> > accurate :).
> 
> I much prefer obvious breakage, in which problem code simply fails to
> compile, to subtle breakage where your code compiles on all the
> systems you have access to but still has subtle problems.

Is it possible to define it to an expression which will cause a warning
if used in a way requiring it to be a constant expression?

If not, that sounds like it could be a useful GCC extension (if maybe one
not so easy to implement).

Cheers,
Ralf