Re: Write to a closed stream bug.

Joerg Weule (
Thu, 18 Dec 1997 10:05:15 +0100

> From Wed Dec 17 21:17 MET 1997
> Date: Wed, 17 Dec 1997 14:51:37 -0500 (EST)
> From: "Richard B. Johnson" <>
> To:
> Cc:, Linus Torvalds <>,
Linux kernel
> Subject: Write to a closed stream bug.
> Mime-Version: 1.0
> X-Orcpt: rfc822;
I agree to the tatement of GNU!
> Gentlemen:
> I discovered a bug in the new glibc 'C' runtime library that has
> far-reaching consequences if one were to recompile existing Linux
> support software.
> I have been communicating privately with GNU. Unfortunately, the
> response has been that I don't know what I'm talking about and
> that the bug isn't a bug at all.
> It is now time for the Linux group to review the consequences of
> having such a bug in the C runtime library. Hopefully, more
> persons than myself will declare that the current behavior is
> unacceptable and force it to be fixed.
> The glibc bug is that a write to a closed file descriptor does not
> return an error.
> This is definitely a bug. If the standards, proposed or existing,
> allow this behavior, the standards are wrong. No 'C' runtime library
> that I have checked during the past two weeks has allowed this behavior.
Would a 64-Bit 'long int' be a bug. I've never seen such a 'long int',
but I'm shure, I will.

> A library function must perform its intended function or return
> information in some manner that shows why the function could not
> 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.
> There is a name for such behavior and it isn't something professionals
> have to use very often.
> The current implementation, as demonstrated, pretends that it does
> something that it did not do.
> #include <stdio.h>
> #include <errno.h>
> int main()
> {
> int i;
> FILE *file;
> file = fopen("/tmp/foo", "w");
> fclose(file);
> i = fprintf(file, "12345678");
> printf("Returned %d %s\n", i, strerror(errno));
> }
> The proposed standard you cited:
> >
> > The current ISO C9X draft says in 7.13.3:
> >
> > [#4] A file may be disassociated from a controlling stream
> > by closing the file. Output streams are flushed (any
> > unwritten buffer contents are transmitted to the host
> > environment) before the stream is disassociated from the
> > file. The value of a pointer to a FILE object is
> > indeterminate after the associated file is closed (including
> > the standard text streams). Whether a file of zero length
> > (on which no characters have been written by an output
> > stream) actually exists is implementation-defined.
> >
> file. The value of a pointer to a FILE object is
> indeterminate after the associated file is closed (including
> This does not relate to the observed bug at all.
> This says that you can make the VALUE of the pointer anything you
> wish after the file was closed. Therefore you can leave its VALUE
> alone or you can change it to NULL (as some do), or you can do anything
> else to its VALUE. This allows your library to release any storage
> associated with the FILE object, or trap subsequent attempts to
> use that pointer after the file was closed, etc.
> It says nothing about attempting to write data to a closed file. Some
> implementations change the value of the pointer to NULL when the file

!!! Ups, where, which environment? Do you are talking of C ?
Passing the value of a variable must not change value of the variable.

> is closed, this allows one to detect user program bugs by seg-faulting
> if an attempt is made to use that pointer again.
> This does not fix the observed behavior unless a close(fd) results in
> any associated FILE object being set to NULL as well.
> The current 'C' standard (ANSI C3.159-1989, called POSIX) also provides:
> printf(3S) Standard I/O Functions printf(3S)
> printf, fprintf, sprintf - print formatted output
> #include <stdio.h>
> printf(), fprintf(), and sprintf() return the number of
> characters transmitted, or return a negative value if an
> error was encountered.
Can't imagine that this is a copy of the sandard. This seems to be a
manual of on operating system. Please fix the manual, if things are not
explaint correctly.

> Richard B. Johnson
> Project Engineer
> Analogic Corporation
> Penguin : Linux version 2.1.70 on an i586 machine (66.15 BogoMips).
> Warning : It's hard to remain at the trailing edge of technology.
Unfortunetly I can't see a bug. Please read the standard carefully.

With regards

Jörg Weule - -