On 04/01/2013 04:48 PM, Eric Blake wrote:
On 04/01/2013 04:36 PM, LRN wrote:
Apparently, the MSVCRT implementation of fseek() is used.
If not, then we should fix the m4 tests to filter out the
buggy W32 fseek and install the gnulib replacement.
I'm unsure of how they work.
What does
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04.04.2013 00:00, Eric Blake wrote:
On 04/01/2013 04:48 PM, Eric Blake wrote:
On 04/01/2013 04:36 PM, LRN wrote:
Apparently, the MSVCRT implementation of fseek() is used.
If not, then we should fix the m4 tests to filter out
the buggy W32
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04.04.2013 00:21, LRN wrote:
On 04.04.2013 00:00, Eric Blake wrote:
On 04/01/2013 04:48 PM, Eric Blake wrote:
On 04/01/2013 04:36 PM, LRN wrote:
Apparently, the MSVCRT implementation of fseek() is
used.
If not, then we should fix the m4
On 04/03/2013 02:21 PM, LRN wrote:
I'm still stumped on how to reproduce this; on latest gnulib.git
installed in a Cygwin setup, I did:
./gnulib-tool --create-testdir --dir=testdir0 fseeko
then in that directory did a configure with a cross compiler:
./configure --host=i686-pc-mingw32
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
it does fseek on stdin.
That is supposed to succeed when stdin is a file, and fail when stdin
is a pipe.
On W32 it always succeeds, even on a pipe, and thus fseek test fails.
Should that be fixed, or marked as XFAIL on W32?
-BEGIN PGP
On 04/01/2013 04:04 PM, LRN wrote:
it does fseek on stdin.
That is supposed to succeed when stdin is a file, and fail when stdin
is a pipe.
On W32 it always succeeds, even on a pipe, and thus fseek test fails.
Should that be fixed, or marked as XFAIL on W32?
That should be fixed, since a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02.04.2013 02:10, Eric Blake wrote:
On 04/01/2013 04:04 PM, LRN wrote:
it does fseek on stdin. That is supposed to succeed when stdin is
a file, and fail when stdin is a pipe. On W32 it always succeeds,
even on a pipe, and thus fseek test
On 04/01/2013 04:25 PM, LRN wrote:
That should be fixed, since a seek succeeding on a pipe is contrary
to POSIX. Is fseek being replaced on W32?
The package that hosts the instance of gnulib on which the failure was
observed is GnuTLS-3.1.5. I'm not sure whether it replaces fseek or
not, i
On 04/01/2013 04:25 PM, LRN wrote:
The package that hosts the instance of gnulib on which the failure was
observed is GnuTLS-3.1.5.
What commit of gnulib was in use by this GnuTLS release? Is it a case
where gnutls needs to pull in a newer version of gnulib, or is it
already something fairly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02.04.2013 02:34, Eric Blake wrote:
On 04/01/2013 04:25 PM, LRN wrote:
The package that hosts the instance of gnulib on which the
failure was observed is GnuTLS-3.1.5.
What commit of gnulib was in use by this GnuTLS release? Is it a
case
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02.04.2013 02:33, Eric Blake wrote:
On 04/01/2013 04:25 PM, LRN wrote:
That should be fixed, since a seek succeeding on a pipe is
contrary to POSIX. Is fseek being replaced on W32?
The package that hosts the instance of gnulib on which the
On 04/01/2013 04:36 PM, LRN wrote:
Apparently, the MSVCRT implementation of fseek() is used.
If not, then we should fix the m4 tests to filter out the
buggy W32 fseek and install the gnulib replacement.
I'm unsure of how they work.
What does 'grep _FSEEK config.status' show?
$ grep
12 matches
Mail list logo
