From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1030 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: printf POSIX compliance Date: Fri, 8 Jun 2012 19:25:06 -0400 Message-ID: <20120608232506.GX163@brightrain.aerifal.cx> References: <20120608144423.GN163@brightrain.aerifal.cx> <20120608145519.GP163@brightrain.aerifal.cx> <20120608150618.GB17860@port70.net> <4FD22C6C.5040704@barfooze.de> <20120608170056.GU163@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1339198184 26663 80.91.229.3 (8 Jun 2012 23:29:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 8 Jun 2012 23:29:44 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1031-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 09 01:29:43 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 1Sd8cg-0007Sl-3G for gllmg-musl@plane.gmane.org; Sat, 09 Jun 2012 01:29:42 +0200 Original-Received: (qmail 32288 invoked by uid 550); 8 Jun 2012 23:29:42 -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 32280 invoked from network); 8 Jun 2012 23:29:41 -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:1030 Archived-At: On Fri, Jun 08, 2012 at 06:07:37PM +0100, Reuben Thomas wrote: > On 8 June 2012 18:00, Rich Felker wrote: > > On Fri, Jun 08, 2012 at 05:46:10PM +0100, Reuben Thomas wrote: > >> > >> Jim Meyering has an analysis of the problem here: > >> > >> http://www.gnu.org/ghm/2011/paris/#sec-2-1 > > > > He makes it a lot more difficult than it has to be... > > Possibly a discussion worth having with Jim? Most obviously on > bug-gnulib@gnu.org, as he's an active gnulib maintainer. I'm not sure it's worth starting a debate. His slides made for an interesting presentation, but in my opinion, the reason it got to be a mess is that his choice to "factor out" the close operation into an exit handler registered with atexit was a fundamentally bad design. It creates additional global state (not to mention the fact that exiting from an atexit handler has some major issues in itself!) and unnaturally breaks up the use and checking of stdout status into unrelated parts of the program, which then required adding ugly and non-portable hacks to determine if closing stdout needs to be checked. There's also the issue that if fd 1 did not exist when the program started and got assigned to another file the program opened, fclose(stdout) could wrongly close that fd; in the worst case (especially with multi-threaded programs) this could then lead to another file getting reassigned to the same fd, and code that's still in the process of writing to the original one could clobber the wrong file. If he'd stuck to closing stdout and checking for errors in the main program flow after the program is done using stdout, everything would remain incredibly simple. By the way, note that my test ferror(stdout)||fclose(stdout) avoids calling fclose if ferror returns nonzero, so you don't clobber the existing errno value, but that's fragile anyway since it's likely that you already clobbered errno elsewhere. Rich