Re: Write to a closed stream bug.

Joerg Pommnitz (
Thu, 18 Dec 1997 16:38:31 +0100

Pavel Machek wrote:
> Hi!
> > > be performed. It is entirely unacceptable for any function, whether
> > > it is in a runtime-library, or is coded by an application, to
> > > pretend that it performed some function that, in fact, it did not.
> >
> > try strcpy(0x12543456, 0x247375394)
> >
> > shock horror it crashes. You passed it a bad pointer. You did the
> > same
> It is ok - strcpy either copies memory, or raises SIGSEGV. That's
> ok. It reported error.
> About scaling: Yes, it is true that checking for this condition would
> require one mov somewhere inn fclose. Do you think that this is an
> issue?
> And: It behaved incorrectly: you gave it some invalid handle. It did
> not *write* anywhere. If you passed invalid handle, that was valid
> enough for data to go *somewhere*, returning success would be
> acceptable.

Imagine the following code:

1: FILE *s1, *s2;
3: s1 = fopen ("foo", "rw"); /* s1 gets assigned */
4: fwrite ("Hello", 1, 5, s1);
5: fclose (s1); /* after this, the system is
6: free to do whatever it wants
7: with the memory pointed to
8: by s1 */
9: s2 = fopen ("bar", "rw"); /* actually, it gets assigned
10: to s2, so s1 and s2 now
11: refer to the same memory */
12: fwrite ("World", 1, 5, s1); /* Ooops, s1 now writes to
file bar!!!! */

This gets even more interesting in a threaded environment:
In this case, the fopen in line 9 might happen in another thread.

So there is no way to get a deterministic behaviour when
passing an fclosed stream to a function and glibc is free
to return whatever it wants (including success). A program
doing such things is buggy and cannot expect anything useful
from libc.