Eric Blake wrote:
> Do we want to offer ftello(fp) as the shorter alternative to
> lseek(fileno(fp),0,SEEK_CUR) for testing seekability?
I don't think we can guarantee that, if we stick to the abstractions laid
out by POSIX. The ftello.html page says
"The ftell() function shall obtain the curr
Eric Blake wrote:
> --- doc/functions/ftell.texi 1 May 2007 15:11:38 - 1.1
> +++ doc/functions/ftell.texi 24 May 2007 16:21:36 -
> @@ -4,10 +4,12 @@
>
> POSIX specification: @url{http://www.opengroup.org/susv3xsh/ftell.html}
>
> -Gnulib module: ---
> +Gnulib module: ftello
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 5/28/2007 7:55 AM:
> Thanks for explaining. I thought you were talking about the lseek call
> inside fflush, not about an lseek call before it.
>
> Since loss of data is a severe condition, I'm adding a note about it:
Tha
Eric Blake wrote:
> --- doc/functions/fseek.texi 1 May 2007 15:11:38 - 1.1
> +++ doc/functions/fseek.texi 24 May 2007 16:21:36 -
> @@ -4,10 +4,12 @@
>
> POSIX specification: @url{http://www.opengroup.org/susv3xsh/fseek.html}
>
> -Gnulib module: ---
> +Gnulib module: fseeko
>
Eric Blake wrote:
> > --- 9,40
> > AC_REQUIRE([gl_UNISTD_H_DEFAULTS])
> > AC_REQUIRE([AC_PROG_CC])
> > AC_CACHE_CHECK([whether lseek detects pipes], [gl_cv_func_lseek_pipe],
> > ! [if test $cross_compiling = no; then
> > !AC_LINK_IFELSE([
> > ! #include /* for off_t */
Eric Blake wrote:
> --- doc/functions/fseek.texi 1 May 2007 15:11:38 - 1.1
> +++ doc/functions/fseek.texi 24 May 2007 16:21:36 -
> @@ -15,4 +17,7 @@ Portability problems not fixed by Gnulib
> @item
> On Windows platforms (excluding Cygwin), this function does not set @code
> {errn
Eric Blake wrote:
> --- doc/functions/lseek.texi 1 May 2007 15:11:38 - 1.1
> +++ doc/functions/lseek.texi 24 May 2007 16:21:36 -
> @@ -4,10 +4,12 @@
>
> POSIX specification: @url{http://www.opengroup.org/susv3xsh/lseek.html}
>
> -Gnulib module: ---
> +Gnulib module: lseek
>
>
Eric Blake wrote:
> > You said that you got an fflush failure on mingw. Could you please
> > show a test program that failed before?
>
> The m4 test suite detected failures on mingw due to this code that got
> invoked prior to the syscmd macro, in an attempt to follow the POSIX rule
> that for see
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 5/28/2007 7:01 AM:
> --- 9,40
> AC_REQUIRE([gl_UNISTD_H_DEFAULTS])
> AC_REQUIRE([AC_PROG_CC])
> AC_CACHE_CHECK([whether lseek detects pipes], [gl_cv_func_lseek_pipe],
> ! [if test $cross_compiling = no;
Eric Blake wrote:
> > It should be possible to write a real test.
> > ...
> > I still don't see a proof that lseek is incorrect on mingw.
>
> I tested by writing test-lseek.c first, and using
>
> echo hi | test-lseek && echo failed
>
> then repeating that test with the benefit of the lseek modul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 5/24/2007 6:12 PM:
Hi Bruno,
>> * tests/test-lseek.c: New file.
>
> It would be better if it would also test errno.
Done like so (and fixing a bug it uncovered in the meantime):
2007-05-28 Eric Blake <[EMAIL PROTECTE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 5/24/2007 6:12 PM:
> Hi Eric,
>
> I still don't see a proof that lseek is incorrect on mingw.
I tested by writing test-lseek.c first, and using
echo hi | test-lseek && echo failed
then repeating that test with the benef
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"),
Eric Blake byu.net> writes:
> > But there are other types of devices as well, such as special character
> > devices (COM: and consoles). It looks safer to include only the regular
> > files:
> > GetFileType ((HANDLE) _get_osfhandle (fd)) == FILE_TYPE_DISK.
>
> At the same time, NUL (correspond
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 5/24/2007 4:08 AM:
>> if (PeekNamedPipe ((HANDLE) _get_osfhandle (fd), NULL, 0, NULL, NULL,
>> NULL))
>
> But there are other types of devices as well, such as special character
> devices (COM: and consoles). It looks sa
Eric Blake wrote:
> I just noticed that lseek on mingw returns 0 instead of -1 on pipes.
> Which means that gnulib's fflush module thinks the pipe is seekable, and
> loses data in the pipe instead of behaving as a no-op as it should in
> trying to reposition the pipe's location.
Indeed, lseek on p
Brian Dessent wrote:
> > However, I'm not sure on mingw how to detect whether an fd is open on a
> > regular file vs. a pipe. Any ideas?
>
> Check out ser-mingw.c from gdb, they have a fair amount of MinGW pipe/fd
> handling code there, e.g.
>
> static int
> fd_is_pipe (int fd)
> {
> if (PeekN
Eric Blake wrote:
> However, I'm not sure on mingw how to detect whether an fd is open on a
> regular file vs. a pipe. Any ideas?
Check out ser-mingw.c from gdb, they have a fair amount of MinGW pipe/fd
handling code there, e.g.
static int
fd_is_pipe (int fd)
{
if (PeekNamedPipe ((HANDLE) _ge
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I just noticed that lseek on mingw returns 0 instead of -1 on pipes.
Which means that gnulib's fflush module thinks the pipe is seekable, and
loses data in the pipe instead of behaving as a no-op as it should in
trying to reposition the pipe's location
19 matches
Mail list logo
