libc: feof(pipe_handle) keeps returning 0 after pipe is closed

[dmik]

Given that stdin of a process is an end of an OS/2 named pipe, the following loop

while (!feof (stdin))
    fread (buf, 1, sizeof (buf), stdin);

will not stop when the other end of the pipe is closed.

While one may argue that the loop is incorrect (since besides the EOF there may be e.g. a permanent read error that isn't checked in the loop), the closed pipe is clearly an EOF condition.

On Linux, the above code does stop when the other end of the pipe is closed and there are some programs that rely on that.

[dmik]

There is one more related problem. On Linux, ferror() for a closed pipe returns 0 while on OS/2 it returns 1. This is also unexpected by many programs (e.g. 7z and rar32 when instructed to compress stdin) that treat this as a fatal error and abort.

In other words, the following program:

    char buffer[4096];
    int n;

    _fsetmode(stdin, "b");


    while (!feof (stdin) && !ferror (stdin))

    {

        n = fread (buffer, 1, sizeof (buffer), stdin);

        printf ("n %d errno %d\n", n, errno);

    }

    printf ("feof (stdin) %d, ferror (stdin) %d\n",

            feof (stdin), ferror (stdin));

being fed a file 22 bytes long on its stdin through a pipe prints this on OS/2:

n 22 errno 57
feof (stdin) 0, ferror (stdin) 1

while this on Linux

n 22 errno 0
feof (stdin) 1, ferror (stdin) 0

[dmik]

errno 57 is ENOTCONN. This error is translated in __read() (lib/sys/__read.c) from ERROR_PIPE_NOT_CONNECTED obtained from DosRead().

According to CPREF, ERROR_PIPE_NOT_CONNECTED is returned by DosRead() on the client when the server has called DosDisconnectNPipe() on its end of the pipe. It turns out that if the server bypasses the DosDisconnectNPipe() call and calls DosClose() directly, the error is not reported to the client, the next read operation simply returns 0 bytes (which is equivalent to EOF and fixes both feof() and ferror()). The CPREF is definitely not certain about what is the right behavior...

Anyway, I think that it makes sense to handle ERROR_PIPE_NOT_CONNECTED specially in __read() by simply ignoring it and returning zero (w/o setting errno). This will fix the problem for servers still using a pair of DosDisconnectNPipe() + DosClose() for closing their end of the pipe.

[bird]

Checked a little bit and seems ERROR_PIPE_NOT_CONNECTED is only used by named pipes. So it should be safe to change read()'s interpretation of this DosRead return code. Implemented in r3776.

[bird]

Forgot to check the feof() thing, but it turns out it's not only related, it's the same problem. _fill(FILE*) sets _IOEOF when _stream_read, i.e. read, returns 0. :-)