lkml.org 
[lkml]   [1997]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectWrite to a closed stream bug.

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.

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
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)

NAME
printf, fprintf, sprintf - print formatted output

SYNOPSIS
#include <stdio.h>

[SNIPPED]


RETURN VALUES
printf(), fprintf(), and sprintf() return the number of
characters transmitted, or return a negative value if an
error was encountered.



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.


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.036 / U:0.776 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site