[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 Oct 2012 17:25:34 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Possible file stream bug
On Wed, Oct 24, 2012 at 11:22:13PM +0200, Paul Schutte wrote:
> Hi,
>
> It is not my code, but I can not see why it is invalid.
C99 7.19.3 Files
ΒΆ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.
Since the value of the pointer-to-FILE is indeterminate after fclose,
any use of it results in undefined behavior.
The error you've encountered is analogous to the error of calling
free() on memory obtained by malloc(), then later calling realloc() on
the already-freed pointer to try to get it back. This is not the
purpose of realloc (or freopen), and fundamentally cannot work in
general, since the pointed-to memory could already have been reclaimed
for another use. In both cases (realloc and reopen), the function must
be used on an object that is still valid, not one which has already
been closed/freed.
The fact that it happens to work on glibc is purely luck (good or bad
luck, depending on your perspective). This is the nature of undefined
behavior - it can lead to your program doing what you wanted it to,
even though the program is wrong.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
