stdio bug

Eric Blake
Thu Sep 7 21:25:00 GMT 2006

POSIX requires "When a standard utility reads a seekable input file and 
terminates without an error before it reaches end-of-file, the utility shall 
ensure that the file offset in the open file description is properly positioned 
just past the last byte processed by the utility."

For an example, POSIX requires these two commands to give the same results:
$ echo 1 2 3 | tr ' ' '\n' > file
$ tail -n +2 file
$ (sed -n 1q; cat) < file

On cygwin, this isn't happening:

$ (sed -n 1q; cat) < file

But on Solaris, it is:

$ (truss sed -n 1q; cat) < file 2>&1 | tail
fstat64(0, 0xFFBEED40)                          = 0
brk(0x00042100)                                 = 0
brk(0x00044100)                                 = 0
read(0, " 1\n 2\n 3\n", 8192)                   = 6
close(1)                                        = 0
close(2)                                        = 0
llseek(0, 0xFFFFFFFFFFFFFFFC, SEEK_CUR)         = 2

Notice the llseek(0,-4,SEEK_CUR) just before _exit, which restored the file 
pointer back to the last character consumed, so that cat could then start up 
from the right location.

I don't know whether a fix to this would lie in fclose() (making sure that on 
input streams, the position of the underlying fd is restored when discarding 
buffered data), or somewhere else, but it would be nice to see this fixed.  And 
it seems like the bug is in cygwin, not sed, since it is the same version of 
GNU sed on both machines.

Eric Blake

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list