Hi Paul,
> > Return code on that as compiled comes back as "1" .
>
> OK, thanks, to move forward on that part, I installed the following
> patch into gnulib.
> ... check for the AIX 7.1 bug
But there is no AIX 7.1 bug. If fstatat would return wrong st_size fields,
the return code would have been 3, not 1. Kevin Brott reported an exit code
of 1, which means, he saved the file as "foo.c", not "fstat-test.c", as was
intended.
$ gcc -Wall fstat-test.c
$ ./a.out
$ echo $?
0
Interesting - would love to know how you got gcc working on an AIX 7.1 system - I'm still working on getting the supporting build tools to compile correctly.
However, you are correct - when I rename the source file to exactly fstat-test.c I get this ...
$ xlc -o fstat-test fstat-test.c
$ ./fstat-test ; echo $?
0
Which would appear to be an slip on my part, because I'm not fully literate (yet) in C, and the implied requirement on the source filename wasn't obvious to me.
The test that you put into openat.m4 succeeds (return code 0) on AIX 7.1
for me.
$ gcc -Wall foo.c
$ ./a.out
$ echo $?
1
$ echo xxx >conftest.file
$ ./a.out
$ echo $?
0
So I think the entire patch is a workaround against a nonexistent bug.
(And if it was a real bug, it would have had to be documented in
doc/posix-functions/fstatat.texi.)
If we do not use fstatat then tar builds and passes almost all of the checks (only the two sparse file ones fail).
If we use fstatat, then almost all of the checks fail - because the resulting binary is dropping zero-byte files into the archives, and doesn't function.
So either there is a bug or enough of a fundamental difference in the way AIX 7.1's new fstatat call works, that it's not usable with the way the existing GNU tar code is trying to use it.