The C standard says "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 returns EOF." glibc seems to ignore the end-of-file indicator, this can be shown by typing a ctrl-d on a blank line on a tty, or by repeatedly calling fgetc on a file which it has reached the end of and which another process is appending to. See also (not mine) http://sourceware.org/glibc/wiki/Feedback#fgetc_function_.2BAC8_compliance_to_standard
I don't know what you see. You have to provide a self-contained small example of what you think is a problem. Then you can reopen the bug.
The problem is, an example _cannot_ be self-contained - it requires interactive tty input or a second process appending to the file. The example code at the link is sufficient (if modified to read stdin instead of a file), if you type the EOF character [ctrl-D on most systems by default], it will correctly report EOF once, but then it will carry on reading text typed after that when it should (according to standard) continue reporting EOF indefinitely until clearerr is called.
(In reply to comment #2) > The problem is, an example _cannot_ be self-contained - it requires interactive > tty input or a second process appending to the file. And what keeps you from writing such a code? Call fork, has the second process feed a file descriptor etc. I haven't seen any indication of a problem and the descriptor is absolutely not sufficient to reproduce any.