Reputation: 2881
On my platform, the following code allows me to successfully read from stdin
even if its end-of-file flag is set, which also remains set after the read. To reproduce the behavior, first type the end-of-file shortcut (Ctrl+D on Unix, Ctrl+Z on Windows) and then type a normal character.
#include <stdio.h>
// first type the shortcut for EOF, then a single character
int main(void) {
getchar();
printf("feof(stdin): %s\n", feof(stdin) ? "true" : "false");
int ch = getchar();
if (ch == EOF) return 0;
printf("%c\n", (char) ch);
printf("feof(stdin): %s\n", feof(stdin) ? "true" : "false");
}
The output I get (after typing the letter f
):
feof(stdin): true
f
feof(stdin): true
From C11 standard (7.21.7.1, The fgetc
function, 3):
Returns
If the end-of-file indicator for the stream is set, or if the stream is at end-of-file, the end-of-file indicator for the stream is set and the
fgetc
function returnsEOF
getchar()
is equivalent to getc(stdin)
(7.21.7.6), which in turn is a macro for fgetc(stdin)
(7.21.7.5). So getchar()
should behave exactly like fgetc(stdin)
.
It seems to me that this is is not standard compliant. Am I missing something?
This question previously referred to C++ (thus the long discussion in comments), but the problem can be narrowed to the C standard library, thus I edited. Still the following information may be relevant:
The behavior is not consistent among platforms:
This question is a follow-up of this one, which is about the fact the cin.clear()
does not seem to unset the end-of-file flag of stdin
, after some useful comments and chat discussion.
Upvotes: 1
Views: 745
Reputation: 2973
On Linux this is indeed a known glibc
bug in stdio implementation: #1190 - from 2005, #19476 - duplicate from 2016 which got fixed only in recent 2.28 build.
Upvotes: 2