bug-m4
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HEAD: inclusion order wrong for input.c


From: Ralf Wildenhues
Subject: Re: HEAD: inclusion order wrong for input.c
Date: Fri, 6 Apr 2007 13:07:55 +0200
User-agent: Mutt/1.5.14 (2007-04-01)

* Eric Blake wrote on Wed, Apr 04, 2007 at 03:21:46PM CEST:
> 
> Are you interested in installing GMP to further test the mpeval module (5 of
> the 6 skips)?

Those tests (26 73 124 125 136) pass with GMP.

> Also, can you show me tests/testsuite.dir/068/testsuite.log
> so I can see why 'stdin seekable' was skipped (hmm, maybe that is an
> autotest bug, for not including logs of skipped tests).

For skipped tests, not even the directories are kept by default.  I
don't think that is generally a bad thing (you can xfail if you want
output instead; however, the xfail condition cannot be done inside the
test); but maybe an option to override this would be useful.

Anyway, here it goes:

#                             -*- compilation -*-
68. others.at:458: testing ...
+ cat
+ set +x
../../m4/tests/others.at:466: m4 -b -d  < in.m4
+ m4 -b -d
+ cat
+ set +x
../../m4/tests/others.at:473: (m4; cat) < in.m4
+ m4
+ cat
+ set +x
../../m4/tests/others.at:478: (sed -ne 1q; cat) < in.m4
+ sed -ne 1q
+ cat
stdout:
+ set +x
../../m4/tests/others.at:479: test "x`cat stdout`" = "x0)trailing data" || \
  { echo "skipping: sed is too greedy on seekable stdin"; exit 77; }
Not enabling shell tracing (command contains a `...` command substitution)
--- /dev/null   2006-05-22 18:44:12.000000000 +0200
+++ /tmp/build/tests/testsuite.dir/at-stdout    2007-04-04 18:36:33.000000000 
+0200
@@ -0,0 +1 @@
+skipping: sed is too greedy on seekable stdin
68. others.at:458: 68. stdin seekable (others.at:458): skipped (others.at:479)


> The failure in 70 is merely a test suite bug:
[...]
> | -m4: write error: No space left on device
> | +m4: write error
> 
> It appears here that Linux explicitly resets errno to 0 rather than leaving
> unchanged if ferror can detect that a failure occurred but doesn't remember
> why; whereas I wrote the test on cygwin which leaves errno unchanged from its
> previous state of ENOSPC.  So the test suite needs to be tolerant of a wider
> variety of error output.  I'm not sure whether the following will catch
> everything, but it hopefully lets the test get further; it may take a couple
> iterations before we settle on the right patch for the testsuite:

With the patch you posted I get:

#                             -*- compilation -*-
70. others.at:606: testing ...
+ set +x
../../m4/tests/others.at:607: test -w /dev/full && test -c /dev/full || {
  echo "Skipping: no /dev/full support";
  exit 77
}
Not enabling shell tracing (command contains an embedded newline)
+ set +x
../../m4/tests/others.at:613: m4 -b -d --help >/dev/full < /dev/null
+ m4 -b -d --help
stderr:
/tmp/build/src/.libs/lt-m4: write error
+ set +x
../../m4/tests/others.at:613: sed 's/^[^:]*[lt-]*m4[.ex]*:/m4:/
        /^m4debug: module/s/opening file.*/opening file/
        s/\(cannot open module [^:]*\):.*/\1/
    ' stderr >&2
Not enabling shell tracing (command contains an embedded newline)
stderr:
m4: write error
+ set +x
../../m4/tests/others.at:614: grep '^m4: write error' stderr
+ grep '^m4: write error' stderr
stdout:
m4: write error
+ mv stderr experr
+ set +x
../../m4/tests/others.at:618: m4 -b -d --version >/dev/full < /dev/null
+ m4 -b -d --version
stderr:
/tmp/build/src/.libs/lt-m4: write error: No space left on device
+ set +x
../../m4/tests/others.at:618: sed 's/^[^:]*[lt-]*m4[.ex]*:/m4:/
        /^m4debug: module/s/opening file.*/opening file/
        s/\(cannot open module [^:]*\):.*/\1/
    ' stderr >&2
Not enabling shell tracing (command contains an embedded newline)
--- experr      2007-04-04 18:38:40.000000000 +0200
+++ /tmp/build/tests/testsuite.dir/at-stderr    2007-04-04 18:38:40.000000000 
+0200
@@ -1 +1 @@
-m4: write error
+m4: write error: No space left on device
70. others.at:606: 70. stdout full (others.at:606): FAILED (others.at:618)


> The failure in 135 is a failure to port a fix from branch-1_4:
[...]

...and passes now, thanks.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]