Hi Eric,
I still don't see a proof that lseek is incorrect on mingw.
> +# define lseek(f,o,w) \
> + (GL_LINK_WARNING ("lseek does not fail with ESPIPE on non-seekable " \
> + "files on some systems - " \
> + "use gnulib module lseek for portability"), \
You expect that lseek fails on all non-seekable files? This is not
guaranteed by POSIX:
"The behavior of lseek() on devices which are incapable of seeking
is implementation-defined."
It also says:
"The lseek() function shall fail if:
[ESPIPE]
The fildes argument is associated with a pipe, FIFO, or socket."
But have you verified with fstat() that stdin is really a pipe, FIFO, or
socket?
> + AC_CACHE_CHECK([whether lseek detects pipes], [gl_cv_func_lseek_pipe],
> + [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([#include <unistd.h>],
> +[#if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
> + Choke me.
> +#endif])],
> + [gl_cv_func_lseek_pipe=yes], [gl_cv_func_lseek_pipe=no])])
It should be possible to write a real test.
> * tests/test-lseek.c: New file.
It would be better if it would also test errno.
You said that you got an fflush failure on mingw. Could you please
show a test program that failed before? Adding such a test program to
the testsuite for 'fflush' would IMO have been the first thing to do.
Then, with the test case, we can hopefully determine whether the problem
is mingw's lseek or in gnulib's fflush.
I claim that there is also and still a bug in gnulib's fflush: POSIX
guarantees an ESPIPE failure only for pipes, FIFOs and sockets. But there
are other types of devices (COM:, NUL: etc.), on which lseek's behaviour
is unspecified. And you got evidence that when lseek behaves in unexpected
ways, gnulib's fflush will lose data.
Bruno
