Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121024214143.GB24157@port70.net>
Date: Wed, 24 Oct 2012 23:41:43 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Possible file stream bug

* Paul Schutte <sjpschutte@...il.com> [2012-10-24 23:22:13 +0200]:
> It is not my code, but I can not see why it is invalid.

beacuse the standard says so

http://port70.net/~nsz/c/c99/n1256.html#7.19.3p4

and in annex j.2 in the undefined behaviour list there is:
"- The value of a pointer to a FILE object is used after the associated file is closed"


also note that the freopen spec says that it closes the underlying
file so there is no reason for a separate fclose (or fflush) anyway

http://port70.net/~nsz/c/c99/n1256.html#7.19.5.4p4

> Here is a strace when linked agains glibc:
> 
> close(1)                                = 0
> open("/dev/tty", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 1
> fstat(1, {st_mode=S_IFCHR|0666, st_rdev=makedev(5, 0), ...}) = 0
> ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
> ...}) = 0

glibc clearly does not do close in freopen

so it detects closed file streams and handles it in some way
masking the error in the program

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.