[Thorrez]

Another weird thing is that sometimes you can read an EOF, then keep reading more real bytes. So EOF doesn't necessarily mean the permanent end.

[jwilk]

The EOF condition for stdio functions is supposed to be sticky, although glibc didn't implement it correctly until 2.28:

https://sourceware.org/bugzilla/show_bug.cgi?id=1190

https://sourceware.org/legacy-ml/libc-alpha/2018-08/msg00003...

> All stdio functions now treat end-of-file as a sticky condition. If you read from a file until EOF, and then the file is enlarged by another process, you must call clearerr or another function with the same effect (e.g. fseek, rewind) before you can read the additional data. This corrects a longstanding C99 conformance bug. It is most likely to affect programs that use stdio to read interactive input from a terminal.

[Thorrez]

Wow, very interesting! That sounds like a somewhat significant change, and I wonder how much stuff will be broken by it.

Although interestingly somehow I'm still seeing the old behavior in Debian Buster with glibc 2.28 with python3.

    import sys
    while True:
        b = sys.stdin.read(1)
        print(repr(b))

With old glibc with both python2 and python3 the EOF isn't sticky (as expected). With 2.28 with python2 the EOF is sticky (like you said). With 2.28 with python3 it's not sticky for some reason.

[jwilk]

In Python 3, file I/O is is implemented using POSIX read(), write() etc., rather than C stdio.

[Thorrez]

Interesting, and EOF on POSIX read() isn't supposed to be sticky?

That seems like a weird situation, that EOF is sticky in some cases but not others.