test results on NetBSD 7.0

[Bruno Haible]

Test results of a Gnulib POSIX testdir on NetBSD 7.0:


1) On both x86 and x86_64

FAIL: test-exp2l
================

../../gltests/test-exp2.h:50: assertion 'z == y' failed
FAIL test-exp2l (exit status: 134)

FAIL: test-expm1l
=================

../../gltests/test-expm1.h:80: assertion 'err > - err_bound / TWO_MANT_DIG && err < err_bound / TWO_MANT_DIG' failed
FAIL test-expm1l (exit status: 134)

FAIL: test-futimens
===================

../../gltests/test-futimens.h:154: assertion 'ctime_compare (&st3, &st2) < 0' failed
FAIL test-futimens (exit status: 134)

FAIL: test-log10l
=================

../../gltests/test-log10.h:68: assertion 'err > - err_bound / TWO_MANT_DIG && err < err_bound / TWO_MANT_DIG' failed
FAIL test-log10l (exit status: 134)

FAIL: test-log1pl
=================

../../gltests/test-log1p.h:64: assertion 'err > - err_bound / TWO_MANT_DIG && err < err_bound / TWO_MANT_DIG' failed
FAIL test-log1pl (exit status: 134)

FAIL: test-log2l
================

../../gltests/test-log2.h:95: assertion 'err > - err_bound / TWO_MANT_DIG && err < err_bound / TWO_MANT_DIG' failed
FAIL test-log2l (exit status: 134)

FAIL: test-logl
===============

../../gltests/test-log.h:68: assertion 'err > - err_bound / TWO_MANT_DIG && err < err_bound / TWO_MANT_DIG' failed
FAIL test-logl (exit status: 134)

FAIL: test-mkfifoat
===================

../../gltests/test-mkfifo.h:36: assertion 'result == 0' failed
FAIL test-mkfifoat (exit status: 134)

FAIL: test-poll
===============

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 (exit status: 2)

FAIL: test-ptsname_r
====================

../../gltests/test-ptsname_r.c:83: assertion 'result == errno' failed
FAIL test-ptsname_r (exit status: 134)

FAIL: test-renameat
===================

../../gltests/test-rename.h:525: assertion 'stat (BASE "file", &st) == 0' failed
FAIL test-renameat (exit status: 134)

FAIL: test-renameat2
====================

../../gltests/test-rename.h:525: assertion 'stat (BASE "file", &st) == 0' failed
FAIL test-renameat2 (exit status: 134)

FAIL: test-rintl
================

../../gltests/test-rintl.c:81: assertion 'rintl (-0.3L) == 0.0L' failed
FAIL test-rintl (exit status: 134)

FAIL: test-utimens
==================

../../gltests/test-utimens.h:130: assertion 'ctime_compare (&st3, &st2) < 0' failed
FAIL test-utimens (exit status: 134)

FAIL: test-utimensat
====================

../../gltests/test-utimens.h:71: assertion 'func (BASE "file", ts) == -1' failed
FAIL test-utimensat (exit status: 134)



2) On x86

FAIL: test-expl
===============

../../gltests/test-exp.h:82: assertion 'err > - err_bound / TWO_MANT_DIG && err < err_bound / TWO_MANT_DIG' failed
FAIL test-expl (exit status: 134)



3) On x86_64

FAIL: test-expl
===============

../../gltests/test-exp.h:58: assertion 'err > - err_bound / TWO_MANT_DIG && err < err_bound / TWO_MANT_DIG' failed
FAIL test-expl (exit status: 134)

[Paul Eggert]

Thanks for doing that. Although I don't know about the math problems, here are
thoughts on the file-related issues.

Post by Bruno Haible
FAIL: test-futimens
===================
../../gltests/test-futimens.h:154: assertion 'ctime_compare (&st3, &st2) < 0' failed
FAIL test-futimens (exit status: 134)>
...
FAIL: test-utimens
==================
../../gltests/test-utimens.h:130: assertion 'ctime_compare (&st3, &st2) < 0' failed
FAIL test-utimens (exit status: 134)

These two appear to because futimens and utimens are not properly marking the
ctime for update after they change a file timestamp. If I'm right, it's a NetBSD
bug that Gnulib cannot easily work around. It's just a guess, though.

Post by Bruno Haible
FAIL: test-utimensat
====================
../../gltests/test-utimens.h:71: assertion 'func (BASE "file", ts) == -1' failed
FAIL test-utimensat (exit status: 134)

This appears to be because utimensat is not failing with errno==EINVAL for
tv_nsec values less than 0 or greater than 999999999 (and not UTIME_OMIT or
UTIME_NOW). If I'm right it's a NetBSD bug that Gnulib could work around though
this is low priority. It's just a guess, though.

Post by Bruno Haible
FAIL: test-renameat
===================
../../gltests/test-rename.h:525: assertion 'stat (BASE "file", &st) == 0' failed
FAIL test-renameat (exit status: 134)
FAIL: test-renameat2
====================

These appear to be because Gnulib tests are too strict about renameat. They
should allow the NetBSD behavior, because it's better than the behavior that
POSIX requires. I installed the first attached patch to try to fix this.

While looking into the utimensat problem I noticed a portability glitch that is
unrelated to these NetBSD issues, and fixed that in the second attached patch.
It's probably just theoretical.

[Bruno Haible]

Post by Paul Eggert

Post by Bruno Haible
FAIL: test-renameat
===================
../../gltests/test-rename.h:525: assertion 'stat (BASE "file", &st) == 0' failed
FAIL test-renameat (exit status: 134)
FAIL: test-renameat2
====================

These appear to be because Gnulib tests are too strict about renameat. They
should allow the NetBSD behavior, because it's better than the behavior that
POSIX requires. I installed the first attached patch to try to fix this.

Thanks. I confirm that these test failures are now gone.

I'm adding a doc update
1) to be precise about the NetBSD version (since these OSes evolve, I try to
avoid statements about "NetBSD" as a whole),
2) to note that the effect of CPPFLAGS="-D_XOPEN_SOURCE=500" is that
/usr/include/stdio.h redirects the 'rename' function to '__posix_rename',
with the effect that configure
- no longer defines RENAME_HARD_LINK_BUG,
- sets REPLACE_RENAME and REPLACE_RENAMEAT to 0 instead of 1.

But I'm confused: Isn't the problem which you described in the "not fixed
by gnulib" section the same as the bug tested for by the RENAME_HARD_LINK_BUG
test in m4/rename.m4 ? Both are about hard links to the same file, no?
One is caught by the configure test (and even not present any more when
-D_XOPEN_SOURCE=500 is used), and the other one requires a workaround in
tests/test-rename.h. What is the difference, then?


2017-08-16 Bruno Haible <***@clisp.org>

rename, renameat: Update doc regarding NetBSD.
* doc/posix-functions/rename.texi: Clarify that when using
-D_XOPEN_SOURCE=500 on NetBSD 7.0, the hard link bug is gone.
* doc/posix-functions/renameat.texi: Be more precise about NetBSD
version.

diff --git a/doc/posix-functions/rename.texi b/doc/posix-functions/rename.texi
index b024b96..12c3be4 100644
--- a/doc/posix-functions/rename.texi
+++ b/doc/posix-functions/rename.texi
@@ -28,7 +28,7 @@ Solaris 9.
@item
This function incorrectly reduces the link count when comparing two
spellings of a hard link on some platforms:
-NetBSD 1.6, Cygwin 1.5.x.
+NetBSD 1.6, NetBSD 7.0 without @code{-D_XOPEN_SOURCE=500}, Cygwin 1.5.x.
@item
This function will not always replace an existing destination on some
platforms:
@@ -60,7 +60,7 @@ is counter-intuitive, so on some systems, @code{rename} fails with
@code{ENOTDIR} if either argument is a symlink with a trailing slash:
glibc, OpenBSD, Cygwin 1.7.
@item
-POSIX requires that @code{renameat} do nothing and return 0 if the
+POSIX requires that @code{rename} do nothing and return 0 if the
source and destination are hard links to the same file. This behavior
is counterintuitive, and on some systems @code{renameat} is a no-op in
this way only if the source and destination identify the same
@@ -68,7 +68,7 @@ directory entry. On these systems, for example, although renaming
@file{./f} to @file{f} is a no-op, renaming @file{f} to @file{g}
deletes @file{f} when @file{f} and @file{g} are hard links to the same
file:
-NetBSD.
+NetBSD 7.0.
@item
After renaming a non-empty directory over an existing empty directory,
the old directory name is still visible through the @code{stat} function
diff --git a/doc/posix-functions/renameat.texi b/doc/posix-functions/renameat.texi
index dd97132..073c179 100644
--- a/doc/posix-functions/renameat.texi
+++ b/doc/posix-functions/renameat.texi
@@ -47,7 +47,7 @@ directory entry. On these systems, for example, although renaming
@file{./f} to @file{f} is a no-op, renaming @file{f} to @file{g}
deletes @file{f} when @file{f} and @file{g} are hard links to the same
file:
-NetBSD.
+NetBSD 7.0.
@item
After renaming a non-empty directory over an existing empty directory,
the old directory name is still visible through the @code{stat} function

[Paul Eggert]

Post by Bruno Haible
Isn't the problem which you described in the "not fixed
by gnulib" section the same as the bug tested for by the RENAME_HARD_LINK_BUG
test in m4/rename.m4 ? Both are about hard links to the same file, no?

Yes and no. Sorry, I had forgotten about that test. As its comment says, it
attempts to detect a bug with rename("a","b") setting st_nlink incorrectly when
"a" and "b" are hard links to the same file. This bug is somewhat independent of
the issue we're talking about.

That test is too strict, as it rejects the NetBSD 7 behavior. I installed the
attached, to try to fix this.

[Bruno Haible]

Hi Paul,

Post by Paul Eggert
That test is too strict, as it rejects the NetBSD 7 behavior. I installed the
attached, to try to fix this.

I confirm that it works fine:

* On NetBSD 7.0, configure finds that
checking whether rename manages hard links correctly... yes
and so REPLACE_RENAME = 0 and REPLACE_RENAMEAT = 0.
And the rename/renameat tests pass.

* On Cygwin 1.5.25, configure find that
checking whether rename manages hard links correctly... no
(because the test program exited with code 8),
and so REPLACE_RENAME = 1 and HAVE_RENAMEAT = 0.
And the rename/renameat tests pass.

Post by Paul Eggert
... that test. As its comment says, it
attempts to detect a bug with rename("a","b") setting st_nlink incorrectly when
"a" and "b" are hard links to the same file. This bug is somewhat independent of
the issue we're talking about.

But the test program does not call stat(), nor does it test st_nlink.
Still confused...

Bruno

[Bruno Haible]

My guess is that when the link count drops to zero, "bad things happen"
and the test fails at that point without needing to call stat or test
st_nlink.

Probably, yes. We should have documented it better then.

The buggy platforms are so old that it might make sense to stop
supporting them, as we can't easily test these failures any more.

I agree for NetBSD 1.6 (its successor came out more than 12 years ago).
Regarding Cygwin 1.5.x, I still have a machine that runs it.

Bruno