From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2198 Path: news.gmane.org!not-for-mail From: Paul Schutte Newsgroups: gmane.linux.lib.musl.general Subject: Re: Possible file stream bug Date: Wed, 24 Oct 2012 23:54:17 +0200 Message-ID: References: <20121024205904.GJ254@brightrain.aerifal.cx> <20121024212534.GL254@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d042ef525d345df04ccd52029 X-Trace: ger.gmane.org 1351115670 22448 80.91.229.3 (24 Oct 2012 21:54:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Oct 2012 21:54:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2199-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 24 23:54:39 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 1TR8uM-0003nl-3V for gllmg-musl@plane.gmane.org; Wed, 24 Oct 2012 23:54:38 +0200 Original-Received: (qmail 15857 invoked by uid 550); 24 Oct 2012 21:54:30 -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 15849 invoked from network); 24 Oct 2012 21:54:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=VjqLwtyEAGX9zqCHBxwAFpd7REp7q7OSgEt2I/XxY0w=; b=sBNRoo20sUcEZIV6C2VkC2iWhc5kDul3G0k0VHyTFO0PrM5GxZlMDA6Rgs+bter0z+ 5BKomGClpYBPZYr5fshaBwthfv5Zh64CGszyYC8apcErt06smjZ8AP3SWgDkoDqH46ZF FLY318z1KtUFJvC8qS22Nb8ThKYggQJTqDxzTWPm23fQ34X/pI/HP/1pXsz7SFs6e7cM WcFWTVklNnH4pHc1/7IVwf11cEdMntpjaaHecAR+F1yy3p+OTPlVdowiPm7V0Z5r5o7E 7gfaBzxYI31sv3Db6z55BkYhPxcG4UhNXOlaTbdtI1nzwMBuY62q01JgkihaUiivDq23 Q/QA== In-Reply-To: <20121024212534.GL254@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:2198 Archived-At: --f46d042ef525d345df04ccd52029 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Rich ! I was thinking in terms of file descriptors which is only integers and not whole data structures. Sorry for wasting your time. BTW Musl is really awesome ! On Wed, Oct 24, 2012 at 11:25 PM, Rich Felker wrote: > 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 > > =B64. 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 > --f46d042ef525d345df04ccd52029 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Rich !

I was thinking in terms of file descriptors which is o= nly integers and not whole data structures.

Sorry for wasting your t= ime.

BTW
Musl is really awesome !


On Wed, Oct 24, 2012 at 11:25 PM, Rich Felker <dalias@aerifal.cx> wrote:
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.

=A0 =A0 C99 7.19.3 Files

=A0 =A0 =B64. A file may be disassociated from a controlling stream by
=A0 =A0 closing the file. Output streams are flushed (any unwritten buffer<= br> =A0 =A0 contents are transmitted to the host environment) before the
=A0 =A0 stream is disassociated from the file. The value of a pointer to a<= br> =A0 =A0 FILE object is indeterminate after the associated file is closed =A0 =A0 (including the standard text streams). Whether a file of zero
=A0 =A0 length (on which no characters have been written by an output
=A0 =A0 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

--f46d042ef525d345df04ccd52029--