Re: PATH_MAX constant expression

Eric Blake wrote: > On 06/20/2011 04:34 PM, Bruno Haible wrote: >> I find it reasonable to use "#ifdef PATH_MAX" in front of every use of >> PATH_MAX, like POSIX requires. >> >>> But later on in test-getcwd, we have code >>> that does #ifndef PATH_MAX, which is no longer reachable because of our >

Re: PATH_MAX constant expression

On 06/20/2011 04:34 PM, Bruno Haible wrote: > I find it reasonable to use "#ifdef PATH_MAX" in front of every use of > PATH_MAX, like POSIX requires. > >> But later on in test-getcwd, we have code >> that does #ifndef PATH_MAX, which is no longer reachable because of our >> guarantee that PATH_MA

Re: [PATCH] test-getcwd: don't stack-allocate PATH_MAX bytes

On 06/20/2011 04:43 PM, Bruno Haible wrote: > Eric Blake wrote: >> --- a/tests/test-getcwd.c >> +++ b/tests/test-getcwd.c >> @@ -26,7 +26,6 @@ >> #include >> #include >> >> -#include "pathmax.h" >> #include "macros.h" >> >> #if ! HAVE_GETPAGESIZE >> > > Hmm, this will now cause test_long_nam

[PATCH] stat: be robust to PATH_MAX definition

Make this stack-allocation of PATH_MAX bytes more robust. * lib/stat.c (rpl_stat): Require reasonable PATH_MAX. * modules/stat (Depends-on): Add verify. Signed-off-by: Eric Blake --- I'm pushing this. ChangeLog|4 lib/stat.c |8 modules/stat |1 + 3 files chang

Re: [PATCH] test-getcwd: don't stack-allocate PATH_MAX bytes

Eric Blake wrote: > --- a/tests/test-getcwd.c > +++ b/tests/test-getcwd.c > @@ -26,7 +26,6 @@ >  #include >  #include > > -#include "pathmax.h" >  #include "macros.h" > >  #if ! HAVE_GETPAGESIZE > Hmm, this will now cause test_long_name to return immediately on HP-UX, without performing a tes

Re: PATH_MAX constant expression

Eric Blake wrote: > Actually, I agree with the first: > > > 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. OK, I've committed it now. > But dislike the second: > > > 2011-06-18 Bruno Haibl

Re: bug in check for stack growth direction in _AC_LIBOBJ_ALLOCA

On 06/20/11 10:54, Eric Blake wrote: > Hmm, we'll need to backport this improved stack-direction testing to > gnulib and libsigsegv, then, Makes sense. I just pushed this gnulib patch, to do that part. Testing this is not something for the fainthearted, as it requires access to all sorts of str

Re: 'float' fixes for FreeBSD, AIX, IRIX

On 06/20/2011 04:51 AM, Bruno Haible wrote: > On IRIX 6.5 - another platform with a "double double" representation for > 'long double' - the situation is simpler. The cc compiler gets LDBL_MANT_DIG > wrong, and gcc gets LDBL_MIN_EXP, LDBL_MIN, LDBL_EPSILON wrong. Have we reported the gcc bug? --

Re: PATH_MAX and test-stat.h

Eric Blake wrote: > 8908 Pathname Variable Values > 8909 The values in the following list may be constants within an > implementation or may vary from > 8910 one pathname to another. > ... > 8912 A definition of one of the symbolic constants in the following list > shall be omitted from the > 8913

Re: test-linkat failure on IRIX

On 06/19/2011 08:48 AM, Bruno Haible wrote: >> IRIX 6.5: >> >> test-linkat.c:234: assertion failed >> ksh[10]: 1760562 Abort(coredump) >> FAIL: test-linkat > > It fails here: > > /* AT_SYMLINK_FOLLOW only follows first argument, not second. */ > errno = 0; > ASSERT (linkat (dfd, BASE "link

Re: POSIX modules status

On 06/19/2011 08:34 AM, Bruno Haible wrote: >> 2 x FAIL: test-linkat > > On AIX 7.1, the linkat() function apparently fails with EINVAL when on > Linux it returns other errno values. Here's the minimal change to make > the test pass. OK to apply? > > > 2011-06-19 Bruno Haible > >

[PATCH] test-getcwd: don't stack-allocate PATH_MAX bytes

This reverts commit 1e33f8d86f, which guarantees that PATH_MAX is always defined (but not necessarily constant). Rather, the test-getcwd code should be robust to POSIX rules for unlimited or varying length maximums; as well as still passing in spite of the HP-UX bug that doesn't define PATH_MAX as

[PATCH] test-stat: don't allocate PATH_MAX bytes

POSIX allows systems (like Hurd) that don't define PATH_MAX, or which define it larger than a reasonable stack allocation should be. The test originally used stack allocation to avoid portability problems with getcwd, but the getcwd-lgpl module solves those. * tests/test-stat.h (test_stat_func):

Re: PATH_MAX on HP-UX

On 06/18/2011 02:22 PM, Bruno Haible wrote: > 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-get

Re: PATH_MAX and test-stat.h

On 06/20/2011 03:21 PM, Bruno Haible wrote: > Eric Blake wrote: >> POSIX states that PATH_MAX, if defined, must be a compile-time constant. > > Please, where does it say this? I cannot find this statement in > . [Line numbers

Re: PATH_MAX and test-stat.h

Eric Blake wrote: > POSIX states that PATH_MAX, if defined, must be a compile-time constant. Please, where does it say this? I cannot find this statement in . Bruno -- In memoriam Neda Agha-Soltan

Re: bug in check for stack growth direction in _AC_LIBOBJ_ALLOCA

Eric Blake wrote: > Hmm, we'll need to backport this improved stack-direction testing to > gnulib and libsigsegv, then This is true for gnulib's alloca.c and c-stack.c. The code in libsigsegv already contains a counter-measure against tail recursion elimination: -

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

On 06/18/2011 06:15 PM, Bruno Haible wrote: > 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 i

Re: bug in check for stack growth direction in _AC_LIBOBJ_ALLOCA

[adding bug-gnulib] On 06/19/2011 11:35 PM, Paul Eggert wrote: > On 06/19/11 12:01, Andy Wingo wrote: >> No, this program also exhibits the same incorrect behavior, for purposes >> of stack growth checking. > > Thanks, I guess we'll have to turn it up a notch. How about the > following test prog

Re: PATH_MAX and test-stat.h

On 06/18/2011 04:18 PM, James Youngman wrote: >> 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

Re: Bug#630902: m4: FTBFS: FAIL: test-readlink

[adding bug-gnulib] On 06/18/2011 12:05 PM, Santiago Vila wrote: > I can't reproduce the failure on Debian "testing" (currently using > linux-image-2.6.38-2-amd64). > > I can reproduce it, however, on the same Debian testing system if I > use the kernel currently available on "unstable" (linux-ima

Re: error: avoid gcc warning

On 06/18/2011 04:08 PM, Bruno Haible wrote: > 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 raise

Re: tests: remove unnecessary dependency

Eric Blake wrote: > I seem to recall that the mere use of the progname module was sufficient > to satisfy a link failure that would otherwise occur if error() is > called (via xmalloc or similar), even if the test-foo.c didn't directly > use "progname.h". Yes, this can happen. In these cases, it i

Re: tests: remove unnecessary dependency

On 06/17/2011 08:39 AM, Bruno Haible wrote: > The following test files don't include "progname.h" although their module > description asks for the 'progname' module. I seem to recall that the mere use of the progname module was sufficient to satisfy a link failure that would otherwise occur if err

'float' fixes for FreeBSD, AIX, IRIX

> > FreeBSD 6.4: > > > > test-isinf.c:151: assertion failed > > Abort trap (core dumped) > > FAIL: test-isinf > > This test failure occurs because lib/isinf.c relies on LDBL_MAX, and on > FreeBSD/x86, LDBL_MAX is Infinity. Ouch. We had known about this bug, see

tests for module 'float'

> 2 x FAIL: test-isinf > FreeBSD 6.4: > > test-isinf.c:151: assertion failed > Abort trap (core dumped) > FAIL: test-isinf This test failure occurs because lib/isinf.c relies on LDBL_MAX, and on FreeBSD/x86, LDBL_MAX is Infinity. Ouch. It's time for a check of the values of . I'm adding t