Paul Eggert wrote:
> 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
On 08/16/2017 11:32 AM, Bruno Haible wrote:
the test program does not call stat(), nor does it test st_nlink.
Still confused
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.
The buggy
Hi Paul,
> 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
Bruno Haible wrote:
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
Paul Eggert wrote:
> > FAIL: test-renameat
> > ===
> >
> > ../../gltests/test-rename.h:525: assertion 'stat (BASE "file", ) == 0'
> > failed
> > FAIL test-renameat (exit status: 134)
> >
> > FAIL: test-renameat2
> >
>
> These appear to be because Gnulib
Bruno Haible wrote:
Test results of a Gnulib POSIX testdir on NetBSD 7.0:
Thanks for doing that. Although I don't know about the math problems, here are
thoughts on the file-related issues.
FAIL: test-futimens
===
../../gltests/test-futimens.h:154: assertion 'ctime_compare
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 > -
