From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2196 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Possible file stream bug Date: Wed, 24 Oct 2012 17:25:34 -0400 Message-ID: <20121024212534.GL254@brightrain.aerifal.cx> References: <20121024205904.GJ254@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1351114465 12031 80.91.229.3 (24 Oct 2012 21:34:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Oct 2012 21:34:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2197-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 24 23:34:33 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TR8am-0006nQ-NV for gllmg-musl@plane.gmane.org; Wed, 24 Oct 2012 23:34:24 +0200 Original-Received: (qmail 8013 invoked by uid 550); 24 Oct 2012 21:34:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 8005 invoked from network); 24 Oct 2012 21:34:16 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2196 Archived-At: 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