views:

95

answers:

1

Is the following program a valid C program?

#include <stdio.h>

int main()
{
    fwrite("x", 1, 1, stderr);
    fflush(stderr);
    fgetc(stderr);
    fwrite("y", 1, 1, stderr);
    return 0;
}

Notice that I try to read from stderr.

When I compile it in Visual C++ 2008, and run it, I get the following output:

xy

which makes sense. However, when I redirect stderr to a file (test.exe 2> foo.txt), I get a "Debug Assertion Failed" window with the message: "Inconsistent Stream Count. Flush between consecutive read and write". Adding a fflush between the read and write does fix the problem. (This happens in debug build. In release builds, the second write silently fails).

Is this behavior correct, or is this a compiler library bug? I couldn't find anywhere any rules describing when reads or writes are illegal in C.

+2  A: 

C99 says in 7.19.5.3 (fopen), paragraph 6:

When a file is opened with update mode ('+' as the second or third character in the above list of mode argument values), both input and output may be performed on the associated stream. However, output shall not be directly followed by input without an intervening call to the fflush function [...], and input shall not be directly followed by output without an intervening call to a file positioning function, unless the input operation encounters end-of-file.

Congratulations for discovering this corner case in practice. The library implementation is completely correct, since you violate the shall quoted above.

And by the way, it is not uncommon to read from stderr. This is useful when stdin and stdout are redirected and no terminal is available. Although C99 doesn't guarantee it to be readable, I remember some cases on POSIX-like systems where this had actually been done.

Roland Illig
I don't see how this addresses the question at all.
anon
It answers the question 99%. Theoretically the "unless" clause at the end may imply that a failed read doesn't count, but I don't think anybody thought of this case, hence it's undefined.
Amnon
@Amnon It says "When a file is opened with update mode" - what makes you think stderr is opened in that mode? And you cannot call positioning functions on stderr.
anon
`stderr` is one of the three streams that is already opened when `main` starts. To explain the behavior, I assumed that `stderr` had been opened as if by calling `fopen`. I didn't find a reference that reading from a write-only stream leads to undefined behavior, so I happended to read the documentation of `fopen`, and I felt this could explain the behavior well enough.
Roland Illig
Why shouldn't I be able to call positioning functions on `stderr`? 7.19.9.4p2 explicitly mentions the effect of calling `ftell` on a text stream.
Roland Illig
@Neil: there's nothing stopping the user from running the program with stderr redirected to a r/w stream. Anyway, I'm now convinced that the code is too borderline (I thought that any sequence of file operations on an valid file handle was defined-- even if it was defined to set error flags).
Amnon
@Amnon Not using standard C.
anon
@Roland text stream != stderr.
anon