|
Message-ID: <20121024212534.GL254@brightrain.aerifal.cx> 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.