3 ms·
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.
by Thorrez 7y ago
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 7y agoThe 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/bugzilla/show_bug.cgi?id=1190 https://sourceware.org/legacy-ml/libc-alpha/2018-08/msg00003.html 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 7y agoWow, 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.